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Guide to the Manual 

This document serves both as a reference manual and as an introduction to Argus. Sections 1 through 
3 present an overview of the language. These sections Wghsght the essential features of Argus. 
Sections 4 through 15 and the appendices form the reference manual proper. These sections describe 
each aspect of Argus m detail, and discuss the proper use of various features. Appendices I and II 
provide summaries of Argus's syntax and data types. Appendix III summarizes some of the pragmatic 
rules for using Argus. 

Since Argus is based on the programming language CLU, the reader is expected to have some 
familiarity with CLU. Those readers needing an introduction to CLU might read Usfcov, B. and Guttag, J., 
Abstraction and Specification in Program Development (MfT Press, Cambridge, 1986). A shorter 
overview of CLU appears m the article Liskov, B., et a/., -Abstraction Mechanisms m CLU" (Corom. ACM, 
volume 20. number 8 (Aug. 1977), pages 564-576). Appendbc IV summarizes the changes made to 
Argus that are not upward compatible with CLU. 

An overview and rationale for Argus is presented in Liskov, B. and Scheffler, R., "Guardians and 
Actions: Linguistic Support for Robust, Distributed Programs" (ACM Transactions on Programming 
Languages and Systems, volume 5, number 3 (July 1983), pages 381-404). 

The Preliminary Argus Reference Manual appeared as Programming Methodology Group Memo 39 In 
October 1983. Since that time several new features have been added to the language; the most 
significant of these are closures (see Section 9.8), a fork statement (see Section 10.4), equate modules 
(see Section 12.4), and a more ftexbte instantiation mechanism (see Section 12.6). An earner version of 
this document appeared as Programming Methodology Group Memo 54 in March 1987; mis version is 
essentially identical, except that the locking policy for the built-in type generator atomlc_array has been 
simplified. 

We would greatly appreciate receiving comments on both the language and this manual. Comments 
should be sent to: Professor Barbara Liskov, Laboratory tor Computer Science, Massachusetts Institute 
of Technology, 545 Technology Square, Cambridge, MA 02139. 

The authors thank all the members of the Programming Methodology group at MfT for their help and 
suggestions regarding the language and this manual, with special thanks going to Bitot Kbtodner, 
Deborah Hwang, Sharon Pert, and the authors of the CLU Reference Manual. 
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Though her unhappy rival was here to keep 
Queen Juno also had a troubled mind: 
What would Jove turn to next? Better, she thought, 
To give the creature to Arestor*s son. 
The frightful Argus whose unnatural head 
Shone with a hundred eyes, a perfect JaJer 
For man or beast: the hundred eyes teak turns 
At staring wide awake in jNrini, and two 
At falling off to sleep; no matter how or 
Where he stood he gazed at to; even when 
His back was turned, he held his prisoner 
In sight and in his care. 



—Ovid, The Metamorphoses, Book 1 

T ran sla t e d by H. Gregory 

The vicing Press, Inc., New York, 1958 
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Overview 

1 .2. Assignment and Calls 

The basic events in Argus are assignments and caUs. The assignment statement x > £, where x is a 
variable and Eis an expression, causes xto denote the object resuming from the evaluation of £ The 
object is not copied. 

A call involves passing argument objects from the caller to the called routine and returning result 
objects from the routine to the caller. For local calls, argument passing is defined in terms of assignment, 
or call by sharing; for remote cads, call by value is used In a local can, the formal arguments of a routine 
are considered to be local variables of the routine and are initialized, by assignment, to the objects 
resulting from the evaluation of the argument expressions. In a remote cat (see Section 2.3), a copy of 
the objects resulting from the evaluation of the argument expressions is made and transmitted to the 
called handler or creator (see Section 2.4). These copies are then used to mirjaHze the formal arguments 
as before. Local objects are shared between the caller and a cased procedure or iterator, but local 
objects are never shared between the caller and a called handler or creator. 

1.3. Type Correctness 

The declaration of a variable specifies the type of the objects which the variable may denote. In a legal 
assignment statement, x > E, the type of the expression Emust be Indudtd in the type of the variable x. 
Type inclusion is essentially equality of types (see Section 12.6), except for routine types. (A routine type 
with fewer exceptions is included m an otherwise identical routine type with more exceptions. See 
Section 6.1 for details.) 

Argus is a type-safe language, in that it is not posstote to treat an object of type T as if it were an object 
of some other types (the one exception is when T is a routine type and S deludes 7). The type safety of 
Argus, plus the restriction that only the code in a cluster may convert between the abstract type and the 
concrete representation (see Section 12.3), ensure that the behavior of an object can be characterized 
completely by the operations of its type. 

1.4. Rules and Guidelines 

Throughout this manual, and especially in the discussions of atomicity, mere are pragmatic rules and 
guidelines for the use of the language. Certain properties that the language would Hke to guarantee, for 
example that atomic actions are really atomic, are difficult or Impossible for the language to guarantee 
completely. As in any useful programming language, programmers have enough rope to hang 
themselves. The rules and guidelines noted throughout the manual (and collected in Appendix IH) try to 
make the responsibilities of the language and the programmer clear. 
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1.5. Program Structure 

An Argus distributed application consists of one or more guardians, defined by guardian modules. 
Guardian modules may in turn use ad the other kinds of modules that Argus provides. Argus 
programmers may also write single-machine programs with no stable state, using Argus as essentially a 
"concurrent CLU." Such programs may be used to start up muJti-guardian applications. Each module is a 
separate textual unit, and is compiled independently of other modules. Compilation is discussed in 
Section 3. 
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2. Concepts for Distributed Programs 

In this chapter we present an overview of the new concepts in Argus that support distributed programs. 
In Section 2.1, we discuss guardians, the module used in Aigus to distribute data. Next, in Section 2.2, 
we present atomic actions, which are used to cope with concurrency and failure, in Section 2.3 we 
describe remote calls, the inter-guardian communication mechanism, in Section 2.4 we discuss 
transmissible types: types whose objects can be sent as arguments or results of remote cans. Finally, in 
Section 2.4 we discuss orphans. 

2.1. Guardians 

Distributed applications are implemented in Argus by one or more modules cased guardians. A 
guardian abstraction is a kind of data abstraction, but R differs from the dels abstractions supported by 
clusters (as found in CLU). in general, data abstractions consist of a set of operations and a set of 
objects. In a cluster the operations are considered to belong to the abstraction as a whole. However, 
guardian instances are objects and their handlers are their operations. Guardian abstraction is similar to 
the data abstractions in Simula and Smafttafc-80; guaidiam aro like class instances. 

A node is a single physical location, which may have multiple processors. A guardian instance resides 
at a single node, although a node may support several guardians. A guardian encapsulates and controls 
access to one or more resources, such as data or devices. Access to the protected resource is provided 
by a set of operations called handlers. Internally, a guardian consists of a collection of data objects and 
processes that can be used to manipulate those objects. In general, there wW be many processes 
executing concurrently in a guardian: a new process is created to execute each handier catt, processes 
may be explicitly created, and there may be other processes that cany out background activity of the 
guardian. 

The data objects erxyipsulated by a guardian are tocaA they cannot be accessed directly by a process 
in another guardian. In contrast, guardians are global objects: a single guardian may be shared among 
processes at several different guardians. A process with a reference to a guardian can cal the guardian's 
handlers, and these handlers can access the data objects instoe the guardian. Handier cats anew access 
to a guardian's local data, but the guardian controls how that data can be manipulated. 

When a node fails, it crashes. A crash is a "clean- failure, as opposed to a "Byzantine" failure. A 
guardian survives crashes of its node (with as high a probabttty as needed). A guardian's state consists 
of sfabfe and volatile objects. When a guardian's node crashes, al processes running inside the guardian 
at the time of the crash are tost, along with the guardian's votatse objects, but the guardian's stable 
objects survive the crash. Upon recovery of the guardian's node, the guardian runs a special recovery 
process to reconstruct its volatile objects from its stable objects. Since the volatile objects are lost in a 
crash, they typtoaNy consist only of redundant data that is used to improve performance (for example, an 
index into a database). The persistent state of an application should be kept in stable objects. 

Guardians are implemented by guardian definitions. These define: 



8 Concepts for Dlttrtbutod Programs 

1 . The creators. These are operations that can be cased to create new guardian instances 
that perform in accordance with the guardian definition. 

2. The guardian's stable and volatile state. 

3. The guardian's handlers. 

4. The background coda. This is code that the guardian executes independent of any handler 
calls, for example, to perform some periodic activity. 

5. The recover coda. This is code that is executed after a crash to restore the volatile objects. 
Guardians and guardian definitions are discussed in Section 13. 

2.2. Actions 

The distributed data in an Argus application can be shared by concurrent processes. A process may 
attempt to examine and transform some objects from their current states to new states, with any number 
of intermediate state changes. Interactions among concurrent processes can leave data in an 
inconsistent state. Failures (for example, node crashes) can occur during the execution of a process, 
raising the additional possibility that data wKl be left in an inconsistent intermediate state. To support 
applications that need consistent data, Argus permits the programmer to make processes atomic. 

We can an atomic process an action. Actions we atomic in that they are both seriaHzable and 
recoverable. By seriaHzable, we mean that toe overall effect of executing multiple concurrent actions is 
as If they had been executed in some sequential order, even though they actually execute concurrently. 
By recoverable, we mean that the overall effect of an action ia "aH-or-notMng:" either aH changes made to 
the data by the action happen, or none of these changes happen. An action that completes all its 
changes successfully commits; otherwise it aborts, and objects that It modified are restored to their 
previous states. 

Before an action can commit, new states of ail modified, stable objects must be written to stable 
storage 1 : storage that survives media crashes with high probability. Argus uses a two-phase commit 
protocol 2 to ensure that either all of the changes made by an action occur or none of them do. if a crash 
occurs after an action modifies a stable object, but before the new state has been written to stable 
storage, the action win be aborted. 

2.2.1. Nested Actions 

Actions in Argus can be nested: an action may be composed of several subadtons. Subacttons can be 
used to limit the scope of failures and to introduce concurrency within an action. 

An action may contain any number of subacttons, some of which may be performed sequentially, some 



'Lampson, B. W., 'Atomic Tranraofera", in Dmtibutod Sytama-ArchhBctun and Jmptejnantelfon, Lack** Notes in Computer 
Science, volume 105, page* 246-265. Springer-Veriag, New York, 1981. 



2 Qray. J. N., "Notes on data base operating systems', in Opening Systems, An M tmnmi Counm, Bayer, R., Ouabain, R. M., 
and Seegmoaer, Q. (sdtors), Lecture Note* in Computer Science, volume 60, pages S6S-4S1. Springer-Veriag. New York, 1S78. 
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concurrently. This structure cannot be observed from outside the action; the overall action is still atomic. 
Subactions appear as atomic actions with respect to other subactions of the same parent. Thus, 
subactions can be executed concurrently. 

Subactions can commit and abort independently, and a subaction can abort without forcing its parent 
action to abort. However, the commit of a subaction is conditional: even if a subaction commits, aborting 
its parent action will abort it. 

The root of a tree of nested actions is called a topacfon. Topaottons have no parent; they cannot be 
aborted once they have committed. Since the effects of a subaction can always be undone by aborting 
its parent, the two-phase commit protocol is used only when topaottons attempt to commit. 

in Argus, an action (e.g., a handler call) may return objects through either a normal return or an 
exception and then abort. The fofiowing rule should be fosswed to avoid violating seriattzabHtty: a 
subaction that aborts should not return any information obtained from data shared with other concurrent 
actions. 

2.2.2. Atomic Objects and Atomic Types 

Atomicity of actions is achieved via the data objects shared among those actions. Shared objects must 
be implemented so that actions using them appear to be atomic. Objects that support atomicity are 
referred to as atomic object*. Atomic objects provide the synehranicaiion «id recovery rieedad to er^ 
that actions are atomic. An atomic type is a type whose objects are aN atomic. Some objects do not need 
to be atomic: for example, objects that are local to a single process. Since the synchronization and 
recovery needed to ensure atomicity may be expensive, we do not require that all types be atomic. (For 
example, Argus provides ail the built-in mutable types of CLU; these types are not atomic.) However, it is 
important to remember that atomic actions must share only atomic objects. 

Argus provides a number of built-in atomic types and type generators. The bunt-in scalar types (null, 
node, bool, char, Int, real, and string) are atomic. Parameterized types can also be atomic. TypfcaHy, 
an instance of a typs generator wW be atomic only if arty actual type parameters are also atomic. The 
built-in immutable type generators (sequence, struct, and one©*) are atomic if their parameter types are 
atomic. In addition, Argus provides three mutable atomic type generators: atomlc__array, 
atomte_recofd, and atomlc_var1ant. The operations on these types are nearly identical to the normal 
array, record, and variant types of CLU. Users may also define fteirown atomic types (see Section 15). 

The implementation of the built-in mutable atomic type generators is based on a simple locking model. 
There are two kinds of locks: read locks ami write looks. When an action calls an operation on an atomic 
object, the imptementatton acquires a took on that oc^ In tr« appropriate mods: It acquires a write took 
if it mutates the object, or a read took if it only examines the object The butt-in types aitow multiple 
concurrent readers, but only a single writer. If necessary, an action is forced to watt until it can obtain the 
appropriate took. When a write took on an object is first obtained by an action, the system makes a copy 
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of the object's state in a new version, and the operations called by the action work on this version 3 . If, 
ultimately, the action commits, this version will be retained, and the old version discarded. A subactton's 
locks are given to Its parent action when it commas. When a topactton commits, its locks are discarded 
and its effects become visfote to other actions. N the action aborts, the action's locks and the new version 
will be discarded, and the old version retained (see Figure 2-1). 

Figure 2-1 : Locking and Version Management Rules for a Subactton S, on Object X 



Acquiring a read lock: 

All holders of write locks on Xmust be ancestors of S. 

Acquiring a write lock: 

AH holders of read and write locks on Xmust be ancestors of S. 
H this is the f irst time S has acquired a write lock on X, 
push a copy of Xon the top of its version stack. 

Commit: 

S"s parent acquires St took on X. 

if 5 holds a write lock on X, then S a version becomes ffs parent's version. 

Abort: 

ffs lock and version (if any) are discarded. 



More precisely, an action can obtain a read lock on an object If every actton holding a wnle lock on that 
object is an ancestor of the requesting action. An action can obtain a writs lock on an object if every 
action holding a (read or write) lock on that object is an ancestor. When a subactton commits, its locks 
are inherited by its parent and its new versions replace those of its parent; when a subactton aborts, its 
locks and versions are discarded (see Figure 2-1). Because Argus guarantees that parent actions never 
run concurrently with their children, these rules ensure that concurrent actions never hold write locks on 
the same object simultaneously. 

The ancestors of a subactton are itself, its parent, Ms parent's parent, and so on; a subactton is a 
descendant of its ancestors. A subactton commits to tfw top if it and all its ancestors, including the 
topactton, oommit. A subactton is a committed descendant ot an ancestor action K the subactton and all 
intervening ancestors have committed. When a topactton attempts to oommit, the two-phase commit 
protocol is used to ensure that the new versions of aN objects modified by the action and aN its committed 
descendants are copied to stable storage. After the new versions have been recorded stably, the old 
versions are thrown away. 

User-defined atomic types can provide greater concurrency than built-in atomic types 4 . An 



*TW8 operational description (and often in this manual) is not meant to constrain imptementon. However, this particular 
description does reflect our current Implementation. 

4 An example can be found in WeM, W. and Lkkov, B., ■Implementation of ReeMent, Atomic Date Types,* ACM Transactor* on 
Programming Languages andSytmms, volume 7, number 2 (April 1 965), pqjee 244480. 
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implementation of a user-defined atomic type must address several issues. First, it must provide proper 
synchronization so that concurrent calls of Rs operations do not interfere with each other, and so that the 
actions that call Rs operations are serialized. Second, R must provide recovery for actions using its 
objects so that aborted actions have no effect. Finally, R must ensure that changes made to its objects by 
actions that commR to the top are recorded property on stable storage. The buttt-in atomic types and the 
mutex type generator are useful in coping with these issues. User-defined atomic types are discussed 
further in Section 15. 

2.JL3. Nested Topactions 

In addition to nesting subactions inside other actions, R is sometimes useful to start a new topactton 
inside another action. Such a nested topactton, unNke a subactton, has no spsciaJ privileges relative to its 
"parent"; for example, R is not able to read an atomic object model e d by Is "parent". Furthermore, the 
commR of a nested topactton is not relative to Rs "parent"; Rs versions are written to stable storage, and 
Rs locks are released, just as for normal topactions. 

Nested topactions are useful for benevolent side effects that change the representation of an object 
wRhout affecting Rs abstract state. For example, in a naming system a name look-up may cause 
information to be copied from one location to another, to speed up subsequent look-ups of the* name. 
Copytog the data wRhhi a nested topactton that commits ensures mat the changes remain tn effect even if 
the "parent" action aborts. 

A nested topactton is used correctly if R is seriataaWe before Rs Twrent". This is true R eRher the 
nested topactton periorms a benevolent side effect, or I ati oonimunicslion between tiie risstod topactton 
and Rs parent is through atomic objects. 

2.3. Remote Calls 

An action running in one guardian can cause work to be performed at another guardian by calling a 
handler provided by the latter guardian. An action can cause a new guardten to be created by calling a 
creator. Handler and creator caHs are remote caHs. RenxtfecaAB are slmlar to local prooecfcreato;for 
example, the calling process waits for the caN to return. Remote case differ from local procedure caHs in 
several ways, however. 

First, the arguments and resuRs of a remote can are passed by value (see below and also Section 14) 
rather than by sharing. This ensures that the local objects of one guardian remain local to that guardian, 
even If their values are used as arguments or resuRs of remote cafe to other gusjdtans. The only objects 
that are passed by sharing m remote caHs are the global objects: guardians, handlers, creators, and 
nodes. 

Second, any remote call can raise the exceptions failure and unavaHable. (Unflke CLU, not all local 
calls can raise failure, see Appendix IV.) The occurrence of faMure means that the call is unexety to ever 
succeed, so there is nopolnt m retrying the call in the future. UnavaMable, on the other hand, means that 
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the call should succeed if retried in the future, but is unHkety to succeed if retried immediately. For 
example, failure can arise because M is impossfole to transmit the arguments or results of the cat (see 
Section 14); unavailable can arise if the guardian being called has crashed, or if the network is 
partitioned. 

Third, a handler or creator can be called only from inside an action, and the cat runs as a subaction of 
the caHing action. This ensures that a remote caN succeeds ai moat once: ether a remote cal completes 
successfully and commits, or it aborts and all of its modifications are undone (provided, of course, that the 
actions involved are truly atomic). Although the effect of a remote cal ooours at most once, me system 
may need to attempt It several times; this is why remote caHs me made within actions. 

2.4. Transmissible Types 

Arguments and results of remote calls are passed by value. This means thai the argument and result 
objects must be copied to produce distinct objects. Not all objects can be copied Nke this; those that can 
are called transmissible objects, and their types me caHed trant/ntaett* types. Only transmissible 
objects may be used as arguments and results of a remote call. In addition, Image objects (see Section 
6.6) can contain only transmissJbte objects. Parameterized types may be tranemiss^ 
and not in others; for example, instantiations of the built-in type generators are tranemissfota only If their 
parameter types are transmissible. While guardians, creators, and harriers are always transmtestote, 
procedures and iterators are never transmissible. 

Users can define new transmissible types. For each transmissible type 7" the external representation 
type of r must be defined; this describes the format in which objects of type T me transmitted. Each 
cluster that implements a transmissible type T must contain two procedures, encode and decode, to 
translate objects of type T to and from their external representation, More Information about defining 
transmlsstote types cm be found in Section 14. 

2.5. Orphans 

An otphan is an action that has had some ancestor "perish" or has had the pertinent results of some 
relative action tost hi a crash. Orphans can arise in Argus due to crashes and explicit aborts. For 
example, when a parent action is aborted, the active descendents It leaves behind become orphans. 
Crashes also cause orphans: when a guardian crashes, a« active actions with an ancestor at the crashed 
guardian and all active actions with committed descendants that ran at the crashed guardian become 
orphans 5 . However, having a descendent that is an orphan does not necessarSy imply that the parent te 
an orphan; as previously described, actions may commit or abort independently of their subactions. 

Argus programmers can largely ignore orphans. Argus guarantees that orphans are aborted before 



8 Walker, E. R, "Orphan Detection in the Argus System", Massachusetts Institute of Technology, Laboratory for Computer 
Science, Technical Report MIT/LCS/TR-326, June 10S4. 
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3. Environment 

The Argus environment ensures complete static type checking of programs. It also supports separate 
compilation and the independence of guardians. 

3.1. The Library 

Argus modules are compiled in the context of a library that gives meaning to external identifiers and 
allows inter-module type checking. The Argus Hbrary contains type information about abstractions; for 
each abstraction, the Hbrary contains a description unit, or DU, describing that abstraction and its 
implementations. Each DU has a unique name and these names form the basis of type checking. 

3.2. Independence of Guardian Images 

The code run by a guardian comes from some guardian image. A guardian image contains ail the code 
needed to cany out any local activity of the guardian; any procedure, Iterator or cluster used by that 
guardian wHI be In its guardian Image. Any handler cafe made by tite guardian, however, are carriedout 
at the called guardian, which contains the code tint performs the can. Thus a guardian is independent of 
the implementations of the guardians It calls and the implementation of a guardian can be changed 
without affecting the implementations of its clients. 

3.3. Guardian Creation 

When a guardian is created, it is necessary to select the guardian image that w» supply the code run 
by the new guardian. To this end, each guardian has an associated creation environment that specifies 
the guardian images tor other guardians it may create. The creation environment is a mapping from 
guardian types to information that can be used to select a guardian image appropriate for each kind of 
node. For greater flexibility, this information can be associated with particular creator objects. 

3.4. The Catalog 

Somehow, guardians must be able to find other guardians to cal tor services. A guardian usually has a 
reference to any guardian it creates. Also, if a guardian can can some other server guardian, it can team 
about the guardians that the server "knows", because guardians can be passed in remote cans. In 
addition, Argus provides a bunt-in subsystem known by a* guardians. Thie subsystem is called the 
catalog. The catalog provides an atomic mapping from names to transmtastote objects. For example, 
when a new guardian is created, ft can be catalogued under some weft-known name, so that other 
guardians can find it in the future. Since we are currently experimenting wfth various interfaces to the 
catalog, we do not include an interface specification here. 
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4. Notation 

We use an extended BNF grammar to define the syntax of Argus, The general form of a production is: 
nonterminal ::= alternative 
| alternative 

I - 

| alternative 

The following extensions are used: 

a i — a list of one or more a's separated by commas: "a" or "a, a" or "a, a, a" etc. 

{a} a sequence of zero or more a's: " " or "a" or "a a" etc. 

[a] an optional a: ""or "a". 

Nonterminal symbols appear in normal face. Reserved words appear in bold face. All other terminal 
symbols are non-alphabetic, and appear in normal face. 

FuH productions are not always shown in the body of this manual; often alternatives are presented and 
explained individually. Appendix I contains the complete syntax. 



18 



>:■:*? -; : .f-. 



5 Lexical Considerations 



19 



5. Lexical Considerations 

A module is written as a sequence of tokens and separators. A token is a sequence of "printing 1 * ASCII 
characters (values 40 octal through 176 octal) representing a reserved word, an Identifier, a literal, an 
operator, or a punctuation symbol. A separator is a "Wank" character (space, vertical tab, horizontal tab, 
carriage return, newline, form feed) or a comment. Any number of separators may appear between 
tokens. 

5.1. Reserved Words 

The following character sequences are reserved word tokens: 

Table 5-1: Reserved Words 



abort 


tflott 


leave 


signals 


action 


etseif 


mutex 


stable 


any 


end 


nil 


string 


array 


enter 


node 


struct 


atomicarray 


equates 


null 


tag 


atomicjeoord 


except 


oneof 


tagcase 


atomkTvariant 


ex* 


others 


tamest 


background 


false 


own 


tagwatt 


begin 


for 


pause 


terminate 


bind 


foreach 


proc 


then 


bool 


fork 


process 


topaction 


break 


guardian 


proctype 


transmit 


cand 


handler 


real 


true 


char 


hancttertype 


record 


type 


cluster 


handles 


recover 


up 


coenter 


has 


rep 


variant 


continue 


if 


resignal 


when 


cor 


image 


return 


where 


creator 


in 


returns 


while 


creatortype 


int 


seize 


with 


cvt 


is 


self 


wtag 


do 


iter 


sequence 


yield 


down 


itertype 


signal 


yields 



Upper and lower case letters are not distinguished in reserved words. For example, 'end*, 'END', and 
'eNd' are all the same reserved word. Reserved words appear in bold face in this document. 



5.2. Identifiers 

An identifier is a sequence of letters, digits, and underscores (_) that begins with a letter or underscore, 
and that is not a reserved word. Upper and lowercase tetters are not distinguished in identifiers. 

In the syntax there are two different nonterminals for identifiers. The nonterminal Un is used when the 
identifier has scope (see Section 7.1); idns are used for variables, parameters, module names, and as 
abbreviations for constants. The nonterminal name is used wlitn the identifier is not subject to scope 
rules; names are used for record and structure selectors, oneof and variant tags, operation names, and 
exceptional condition names. 



20 Lexical Considerations 

5.3. Literals 

There are literals for naming objects of the built-in types null, bod, Int. real, char, and string. Their 
forms are described in Appendix I. 

5.4. Operators and Punctuation Tokens 

The following character sequences are used as operators and punctuation tokens. 

Table 5-2: Operator and Punctuation Tokens 



( [ 

) 1 



< ~< - 

|| <- -<■ «•■ 

// + >■ ~>« & 

/ > ~> I 



5.5. Comments and Other Separators 

A comment is a sequence of characters that begins with a percent sign (%), ends with a newKne 
character, and contains only printing ASCII characters (including blanks) and horizontal tabs in between. 
For example: 

z > a{l] + % a comment in an expression 

m 

A separator is a blank character (space, vertical tab, horizontal tab, carriage return, newHne, form feed) 
or a comment. Zero or more separators may appear between any two tokens, except that at least one 
separator is required between any two adjacent rwn-self-terminatkig tokens: reserved words, identifiers, 
integer literals, and real literals. This rule is necessary to avoid lexical ambiguities. 
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6. Types, Type Generators, and Type Specifications 

A type consists of a set of objects together with a set of operations used to manipulate the objects. 
Types can be classified according to whether their objects are mutable or Immutable, and atomic or 
non-atomic. An immutable object (e.g., an integer) has a value mart never varies, white the value (state) 
of a mutable object can vary over time. Objects of atomic types provide serialzablttty and recovery for 
accessing actions. Afon-atomfc types may provide synchronization by specifying that particular operations 
are executed indivisibtyon objects of the type. An operation is indivisible if no other process may affect or 
observe intermediate states of the operation's execution. IndMsfcMty properties wffl be described for all 
the built-in non-atomic types of Argus. 

A type generator is a parameterized type definition, representing a (usually infinite) set of related types. 
A particular type is obtained from a type generator by writing the generator name along with specific 
values for the parameters; for every distinct set of legal values, a distinct type is obtained (see Section 
12.6). For example, the array type generator has a single parameter that determines the element type; 
array[lnt], arraylreal], and arrayfarray[lntl] are three distinct types defined by the array type generator. 
Types obtained from type generators are catted parameterized types or instantiations of the type 
generator; others are catted simple types. 

In Argus code, a type is specified by a syntactic construct catted a typejspec. The type specification 
for a simple type is just the identifier (or reserved word) naming the type. For parameterized types, the 
type specification consists of the identifier (or reserved word) naming the type generator, together with the 
actual parameter values. 

To be used as arguments or results of handier and creator calls, or as Image objects (see Section 6.6), 
objects must be transmissible. Most of the built-in Argus types are transmissible, that is, they have 
transmissible objects. However, procedures and iterators are mm tranemisstole. For type generators, 
transmissttritty of a particular instantiation of the generator may depend upon transmisstoility of any type 
parameters. A transmisstote type provides the pseudo-operation transmit and two internal operations 
encode and decode. Generally, encode and decode am hidden from dents of the type. They are catted 
implicitly during message transmission (see Section 14) and in creating and decomposing Image objects 
(see Section 6.6). TransnrissbiHty is discussed further in Section 14. 

Argus provides ail me built-in types of CLU as well as some new types and type generators. This 
section gives an informal introduction to the built-in types and type generators provided by Argus. Many 
details are not discussed here, but a complete definition of each type and type generator is given in 
Appendix II. 
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The binary operations **/(+), sub(-), mul(% dbt(l), mod{ll) t powern, max, and min are provided, as 
weH as unary minus (-) and ate. There are binary comparison operations /*(<), fe(<-), equal H, 
ge (>-), and gt(>). There are two operations, *oro_to and trom_p_by, for iterating over a range of 
integers. See Section 11.4 for details. 

6.2.4. Real 

The type real models (a subset of) the mathematical real numbers. The exact subset is not part of the 
language definition. Reals are immutable, atomic, and transmissible, although transmission of real 
objects between heterogeneous machine architectures may not be exact. Real literals are written as a 
mantissa with an optional exponent. A mantissa is either a sequence of one or more decimal digits, or 
two sequences (one of which may be empty) Joined by a period. The mantissa must contain at least one 
digit. An exponert is 'F or 'e\ optional Wto^ An 

exponent is required if the mantissa does not contain a period. As to usual, m£x- m*lO*. Examples of 
real literals are: 

3.14 3.14E0 314e-2 .0314E+2 3. .14 

As with integers, the operations add{+), sub(~), rou/(*), dn/(/), nwd(//), power?*), max, min, 
minus (-), ate, H (<), to (<-), equal («), ge (>-), and gt (>), are provided. It to important to note that there 
to no form of ^Jeff convention between types. The fir operation converts an integer to a real, t2l rounds 
a real to an integer, and mine truncates a real to an integer. See Section H.5 for details. 

6.2.5. Char 

The type char provides the alphabet for text manipulation. Characters are immutable, atomic, 
transmissible, and form an ordered set. Every implementation must provide at toast 128, but no more 
than 51 2, characters; the first 1 28 characters are the ASCII characters in their standard order. 

Literate for the printing ASCII characters (octal 40 through octal 176), other than single quote (') or 
backslash (\), can be written as that character enclosed in single quotes. Any character can be written by 
enclosing one of the escape sequences listed in Table 8-1 in single quotes. The escape sequences may 
be written using upper case totters, but note that escape sequences of the form \&* are case sensitive. A 
table of literate to given at the end of Appendix I. Examples of character NteraJs are: 
\T 'a' "" V \" "\B' M77' 

There are two operations, 12c and c2l, for converting between integers and characters: the smallest 
character corresponds to zero, and the characters are numbered sequentially. Binary comparison 
operations exist for characters based on this numerical ordering: *(<), to(<-), equal (-), ge (>-), and 
gf(>). For details, see Section 11.6. 
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the mutability and atomicity of an any object depend on the mutability and atomicity of the contained 
object. Objects of type any are not transmissible. 

The create operation is parameterized by a type; ornate takes a single argument of that type and 
returns an any object containing the argument. The force operation is also parameterized by a type; it 
takes an any and extracts an object of that type, signaWng »mng__type if the contained object's type is 
not included in the parameter type. The fej^ operation is paramsterteed by a type art 
its argument contains an object whose type is included in the parameter type. The detailed specification 
is found in Section 11.19. 

6.2.8. Sequence Types 

Sequences are immutable and they are atomic or transrrtsstole when instantiated with atomic or 
transmissible type parameters. Although an individual sequence can have any length, the length and 
members of a sequence are fixed when the sequence is created. The elements of a sequence are 
indexed sequentially, starting from one. A sequence type specification has the form: 

sequence [ type_actual ] 
where a typa_actualis a typejspec, possibly augmented with operation bindings (see Section 12.6). 

The new operation returns an empty sequence. A sequence constructor has the form: 
type_spec$ [ [ expression , ... ] ] 
and can be used to create a sequence with the given elements. 

Although a sequence, once created, cannot be changed, new sequences can be constructed from 
existing ones by means of the addh, add, remh, and rami operations. Other operations include fetch, 
replace, top, bottom, size, the elements and indexes Iterators, and aubaaq. Invocations of the fetch 
operation can be written using a special form: 

qfl] % fetch the element at index! of q . 

Two sequences with equal elements are equal. The equal (m) operation tests if two sequences have 
equal elements, using the equal operation of the element type. Similar tests if two sequences have 
similar elements, using the similar operation of the element type. 

All operations are indivisible except for flUjoopy, equal, similar, copy, encode, and decode, which are 
divisible at calls to the operations of the type parameter. 

For the detailed specification, see Section 11.8. 

6.2.9. Array Types 

Arrays are one-dimensional, and mutable but not atomic. They are transmissbie only if their type 
parameter is transmisstole. The number of elements in an array can vary dynamically. There is no notion 
of an "uninitialized" element. 



MP 



T^ ; ''^■-• : - 



IPHMHiiiil 



26 



Tfm 




teftit: 



Thtm «t a nun*« of wap 




Ml 




♦ »»» J 



6.2.10 Structure Types 

27 

A structure is created using a structure constructor. For example, assuming that "info" has been 
equated to a structure type: 

info - structpast, first, middle: string, age:lnt] 
the following is a legal structure constructor: 

info $ {last: "Scheifler", first: "Robert", age: 32, middle: "W."} 
An expression must be given for each selector, but the order and grouping of selectors need not 
resemble the corresponding type specification. 

For each selector "sei", there is an operation get_j»l to extract the named component, and an 
operation replace_sel to create a new structure with the named component replaced with some other 
object. Invocations of the get operations can be written using a special form: 
«.age % get the 'age' component of st 

As with sequences, two structures with equal components are in fact the same object. The equal (-) 
operation tests if two structures have equal components, using the equal operations of the component 
types. Similar tests if two structures have similar components, using the similar operations of the 
component types. 

All operations are indMsble except for equal, similar, copy, encode, and decode, which are dMsfole at 
calls to the operations of the type parameter. 

For the detailed specification, see Section 11.11. 

6.2.11. Record Types 

A record is a mutable collecttontf one or rnorenam^ Records are never atomic, and are 

transmissble only if the parameter types are aN transmissible. A record type specification has the form: 

record [ field_spec , ... ] 
where (as for structures) 

field_spec :."= name , ... : type_actual 
Selectors must be unique within a specification, but the ordering «to grouping tf selector 

A record is created using a record constructor. For example : 
professors {last: "HerUhy"* first: "Maurice", age: 32, middle: "P.") 

For each selector "set", there Is an operation get_sel to extract the named component, and an 
operation set_sel to replace the named component with some other object. Invocations of these 
operations can be written using a special form: 

r.middle % get the 'middle' component of r 

rage :- 33 % set the 'age' component of r to 33 (by calling set_age) 

As with arrays, every newly created record has an identity that is distinct from all other records; two 
records can have the same components without being the same record object. The identity of records 



28 Types, TvpeGenen«ors, and Type Specifications 

can be distinguished with the equal (-) operation. The sknHarl operation tests N two records have equal 
components, using the equal operations of the component types. Sfmftrtests IT two records have similar 
components, using the similar operations of the component types. 

All operations are indivisible, except similar, similar 1, copy, encode, and decode, which are divisible at 
calls to operations of the type parameters. 

For the detailed specification, see Section 11.12. 

6.2.12. Oneof Types 

A onwi type is a tagged, discriminated union. A oneof is an Immutable labeled object, to be thought of 
as "one of" a set of alternatives. The label is cafted the tag, and the object is called the value. A oneof 
type specification has the form: 

oneof [ fleM_spec , ... ] 
where (as for structures) 

field_spec ::= name , ... : type_actual 
Tags must be unique within a specification, but the ordering and grouping of tags is unimportant. An 
instantiation is atomic or transmtesWe If and only if ail the type parameters are atomic or transmissible. 

For each tag T of a oneof type, there is a make_J operation which takes an object of the type 
associated with the tag, and returns the object (as a oneof) labeled wllh tag T. 

To determine the tag and value of a oneof object, one normally usee the tagcaee statement (see 
Section 10.14). 

The equal H operation tests if two oneofs have the same tag, and if so, tests if the two value 
components are equal, using the equal operation of the value type. S*n*ar tests if two oneofs have the 
same tag, and if so, tests If the two value components an similar, using the similar operation of the value 
type. 

AH operations are indivisible, except equal, similar, sfmHarl, copy, encode, and decode, which are 
divisible at calls to operations of the type parameters. 

For the detailed specification, see Section 11.14. 

6.2.13. Variant Types 

A variant is a mutable oneof. Variants are never atomic and are transmissible If and only if their type 
parameters are all transmissible. A variant type specification has the form: 

variant [field_spec,...] 
where (as for oneofs) 

field_spec ::= name , ... : type_actual 



6.2.13 Variant Types 
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The state of a variant is a pafr consisting of a laoetcaJM Foreach 

tag T of a variant type, there is a makej operation which takes an object of the type associated with the 
tag, and returns the object (as a variant) labeled wHh tag T. in addition, there is a changej operation, 
which takes an existing variant and an object of the type associsAsd wlh T, and changes ths~state of the 
variant to be the pair consisting of ths tag T and the given object. To determine the tag and value of a 
variant object, one normally uses the tagcase statement (see Section 10.14). 

Every newly created variant has an identity that is distinct from at other variants; two variants can have 
the same state without being the same variant object. The identify of variants can be distinguished using 
the equal (-) operation. The slmllarl operation tests if two variants have the same tag, and if so, tests if 
the two value components are equal, using the equal operation of the value type. Similar tests if two 
variants have the same tag, and if so, tests if the two value components are similar, using the similar 
operation of the value type. 

All operations are indivisible, except similar, similar 1, copy, encode, and decode, which are dMsble at 
calls to operations of the type parameters. 

For the detailed specification, see Section 11.15. 



6.2.14. Procedure and iterator Types 

Procedures and iterators are created by the Argus system or by ths bind expression (see Section 9.8). 
They are not transmissbie. As the identity of a procedure or iterator is immutable, they can be 
considered to be atomic. However, their atomicity can be violated If a procedure or Nerator has own data 
and thus a mutable state. The immutability and atomicity of a procedure or iterator with own data 
depends on that operation's specified semantics. 

The type specification for a procedure or iterator contains most of the information stated in a procedure 
or iterator heading; a procedure type specification has the form: 

proctype ([ type_spec ,...])[ returns ][ signals ] 
and an iterator type specification has the ft >rm: 

Kertype ([ type_spec ,...])[ yiefcfti ][ signals ] 



where 



returns 
yields 
signals 
exception 



= returns ( type_spta , ... ) 

= yields ( type_spe< ) 

= signals ( exception , ... ) 
= nams [ ( type.spec ,...)] 



and 



The first list of type specifications describes 
yields clause gives the number, types, 
clause lists ths exceptions raised by the 
types, and order of the objects to be returned 
unique. The ordering of exceptions is not 



ths number, types, and order of arguments. Ths returns or 
order of the objects to be returned or yielded. Ths signals 

procedure or iterator; for each exception name, the number, 
is also given. AH names used in a signals clause must be 

important. 
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Procedure and iterator types have an equal («) operation. Invocation is not an operation, but a 
primitive in Argus. For the detailed specification of proctype and Kertype, see Section 11.17. 

6.3. Atomic_Array, Atomic_Record, and Atom!c_Variant 

Havlno described the types that Argus inherited from CLU, we now describe the new types in Argus. 
The mutable atomic type generators of Argus are stomte_array, atomte_recofd, and atomte_vsrtant. 
Types obtained from these generators provide the same operations as the analogous types obtained from 
array, record, and variant, but they differ in their synchronization and recovery properties. Conversion 
operations are provided between each atomic type generator and to non-atomic partner (for example, 
atomlc_array[t]$aa?a converts from an atomic array to a (non-atomic) array). 

An operation of an atomic type generator can be classified as a reader or writer depending on whether 
it examines or modifies its principal argument, that is, the argument or result object of the operation's 
type. (For binary operations, such as ar_jpt8_ar, the operation is classified with respect to each 
argument.) Intuitively, a reader only examines (reads) the state of its principal argument, whs* a writer 
modifies (writes) its principal argument. Operations that create objects of an atomic type are classified as 
readers. Reader/writer exclusion is achieved by locking: readers acquire a read lock whse writers 
acquire a write lock. The locking rules are discussed in Section 2.2.2. 

If one or more of the type parameters is non-atomic, then the resulting type is not atomic because 
modifications to component objects are not controlled. However, read/write locking still occurs, as 
described above. Thus, an atomic type generator instantiated wth a rwr^atwnic parameter irxajrs the 
expense of atomic types without gaining any benefit; such an instantiation is unHkefy to be a correct 
solution to a problem. Atomic type generators yield transmissbie types only tf the type parameters are aH 
transmisstole. 

Special operations are provided for each atomic type generator to test and manipulate the locks 
associated with reader/writer exclusion. These operations are useful for implementing user-defined 
atomic types (see Section 15). The tagteet and tagwaH statements (see Section 10.15) provide 
additional structured support for atomte_variants. The operations can_read, oanjwrm, Test_and_read, 
and test_and_wrlte provide relatively unstructured access to took information. For complete definitions of 
these operations, see Sections 11.10, 11.13, and 11.16. 

Assuming normal termination, the following operations acquire read locks on their principal arguments 
or the objects that they create. 

atomlc_array: create, new, predict, mi, m_copy, size, tow, high, empty, top, bottom, fetch, similar, 
stmUarl, copy, copyl, elements, Indexes, test and read, a2aa. aa2a, encode, 
decode """ "~ 

atomlcjecord: create, get_ , similar, simUarl, copy, copyl, test and read, ar gets ar (second 
argument), r2ar, ar2r, encode, decode — — — _ 

atomlc_vai1ant: make_ is_ , vaJue^ , av_gets_av (second argument), similar, similarl, copy, copyl, 
tBst_and_read, v2av, av2v, encode, decode 
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The operations simitar and sknHarl acquire read locks on both arguments. The operations copy and 
copy f acquire a read lock on the value returned as wed as their principal argument. Test_and_read is a 
reader only if it returns true; otherwise It is neither a reader nor a writer. 

Assuming normal termination, the following operations acquire write locks on their principal arguments. 
atomlc_arTay: setjow, Mm, store, addh, add, remh, reml, teet_and_write 
atomlc_record: set_ , arj/etsjv (first argument), te*t_and_wrHe 
atomie.vartant: change_ , avjgetsjw (first argument), mtjandjmm 

TestjandjMrite is a writer only if it returns true; otherwise It is neither a reader nor a writer. 

The equal, canjead, and canjmHe operations are neither readers nor writers. 

When an operation of atomto__atT«y terminates with an exception, Its principal argument is never 
modified ; however, the atomlc_array operations listed above as writers always obtain a write lock before 
the principal argument is examined, hence there are cases In which they wK obtain a write lock and only 
read, but not modify their principal argument. For example, atomte_arrayftj$fr*n is a writer when it 
signals bounds. On the other hand, when an atomtc_afray operation raises a signal because of an 
invalid argument, no locks are obtained. For example, when atomte_amryp)$fr*n signals n*gatoe_size, 
it is neither a reader nor a writer since the array's state is neither examined nor modified (only the Integer 
argument is examined). 

For the detailed specification of atomic arrays, see Section 11.10; for atomic records, see Section 11.13; 
and for atomic variants, see Section 11.16. 

6.4. Guardian Types 

Guardian types are user-defined types that are implemented by guardian definitions (see Section 13). 
A guardian definition has a header of the form: 

idn- guardian [parms] la idn,... [ handles idn ,...][ where ] 
The creators are the operations named m the identifier list following la; a creator is a special kind of 
operation that can be called to create new guardians mat behave in accordance with the guardian 
definition. Each guardian optionally provides handlers that can be called to interact with It; the names of 
these handlers are listed In the Identifier list following hanchoe. (See Section 13 for more details.) 

A guardian definition named g defines a guardian interface type g. An object of the guardian interlace 
type provides an interface to a guardian that behaves in accordance with the guardian definition. An 
interface object is created whenever a new guardian is created, and then the interface object can be used 
to access the guardian's handlers. Interface objects are transmiseWe, and after transmission they still 
give access to the same guardian. In this manual a "guardian interface object- ie often cased simply a 
"guardian object". 

The guardian type g for the guardian definition named g has the fosowing operations. 
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1 . The creators listed in the Is Hst of the guardian definition. 

2. For each handler name h listed m the handles Hst, an operation get h with type: 
proctypsto) returns (to), where Mis the type of h. ~~ 

3. Equal and similar, both of type: proctype (g, g) returns (boot), which return true only M 
both arguments are the same guardian object. 

4. Cepy, of type: proctype (g) returns (g), which simply returns Ms argument. 

5. transmit. 

A creator may not be named equal, similar, copy, print, or get_h where ft te the name of a handler. 

Thus if x is a variable denoting a guardian Interface object of type g, and h is a handler of g, men 
g$get_h(x) will return mis handler. As usual with gef_ operations, this cal can be abbreviated to xJi. 
Note that the handlers themselves are not operations of the guardian Interface type; thus g$h would be 
illegal. 

A guardian interface type is somewhat Hke a structure type. Its objects are constructed by the creators, 
and decomposed by the gef_ operations. Guardian interface objects are immutable and atomic. 

6.5. Handler and Creator Types 

Creators are operations of guardian types. Handier objects are created as a side-effect of guardian 
creation. Unlike procedures and iterators, handlers and creators are transmisstols. 

The types of handlers and creators resemble the types of procedures: 
hsndlsrtyps< [typs.spsc. ... ] ) [ returns ][ signals ] 
««ortyps([typs_spec,..J) [returns] [signals] 

The argumert, normal result, and exc^ptlwi resu* types nrwst ail be trsnsmisstole. The signal* 1st for a 
handlertype or crestortype cannot include either failure or unavailable, as these signals are knpscft in 
the Interface of all creators and handlers. 

Handler and creator types provide equal and similar operations which return true if and only If both 
afgumemsarethesaimobje« l «idccwopef^ Forthedetafted 

specification of handlertype and creatortype, see Section 11.18. 

6.6. Image 

The Image type provides an escape from compile-tims type checking. The main difference between 
lms^andsnyi8thatlms^c«je{^aretransmissibie. An knags object can be thought of as a portion 
of an undecoded message or as the information rieecfed to recreate an object tf knags 

objects are immutable and atomic. 

The create operation is parameterized by a transmissible type; it takes a single argument of that type 
and encodes it (using the encode operation of that type) into an Image object. The force operation is also 
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parameterized by a transmtesfote type; It takes an Image object and decodes it (using the decode 
operation of that type) to an object of that type, signaling wrongjype if the encoded object's type is not 
included in the parameter type. The bjype operation ie parameterized by a type and checks whether its 
argument is an encoded object of a type included in the parameter type. See Section 11.20 for the 
detailed specification. 

6.7. Mutex 

Mutex objects are mutable containers for information. They are not atomic, but they provide 
synchronization and control of writing to stable storage tor their contained object. Mutex itself does not 
provide operations tor synchronizing the use of mutex objects. Instead, mutual exclusion is achieved 
using the seize statement (see Section 10.16), which allows a sequence of statements to be executed 
while a process is in exclusive possession of the mutex object. Mutex objects are transmissible if the 
contained object Is transmisstole. 

The type generator mutex has a single parameter that is the type of the contained object. A mutex 
type specification has the form: 

mutex [type_actua(] 
Mutex types provide operations to create and decompose mutex objects, and to notify the system of 
modifications to the mutex object or its contained object. 

The create operation takes a single argument of the parameter type and creates a new mutex object 
containing the argument object The get^yatue operation obtains the contained object from its mutex 
argument, whNe Mt_yalue modifies a mutex object by replacing its contained object. As with records, 
these operations can be catted using special forms, for example: 

m: mutexflntl :- mutexftotjlcreate (0) 

x: tat :- ravakie % extract the contained object 

m.value:-33 % change the contained object 

SetjraJue and get_value are indMstole. 

Mutexes can be distinguished with the equal (-) operation. There are no operations that could cause 
or detect sharing of the contained object by two mutexes. Such snaring is dangerous, since two 
processes would not be synchronized with each other in their use of the contained object if each 
possessed a different mutex. In general, If an object is contained in a mutex object, it should not be 
contained in any other object, nor should it be referred to by a variable except when in a seize statement 
that has possession of the containing mutex. 

There are some mutex operations that seize the mutex object automaticaiiy. Copy seizes its single 
argument object. Sftnflarseizes its two argument objects; the first aigument object is seized first and then 
the second. In both cases possession is retained untl the operations return. Also, when a mutex object 
is encoded (for a message or when making an image), the object is seized automatically. See Section 
11.21 for the detailed specification of mutex. 
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Mutexes are used primarily to provide process synchronization and mutual exclusion on shared data, 
especially to implement user-defined atomic types. In such imptementatons, it is important to control 
writing to stable storage. The mutex operation changed provides the necessary control. Changed 
informs the system that the calling action requires that the argument object be copied to stable storage 
before the commit of the action's top-level parent (topaction). Any mutex is asynchronous: its contained 
object is written to stable storage independently of objects that contain that mutex. See Section 15 for 
further discussion of user-defined atomic objects. 

6.8. Node 

Objects of type node stand for physical nodes. The operation hen takes no arguments and returns 
the node object that denotes its caller's node. Equal, similar, and copy operations are also provided. 

The main use of node objects is in guardian creation (see Section 13), where they are used to cause a 
newly created guardian to reside at a particular node. Objects of type node are immutable, atomic, and 
transmissible. For the detailed specification, see Section N.2. 

6.9. Other Type Specifications 

A type specif (cation for a user-defined type has the form of a reference: 
reference ::= idn 

| idn [ actual_parm , ... ] 
| reference $ name 
where each actual jtarm must be a corpse-time computable constant (see Section 72) or a type_actuaJ 
(see Section 12.6). A reference must denote a data abstraction to be used as a type specification; this 
syntax is provided tor referring to a data abstraction that is named in an equate module (see Section 
12.4). For type generators, actual parameters of the appropriate types and number must be suppled. 
The order of parameters is always significant for user-defined types (see Section 12.5). 

There are two special type specifications that are used when Implementing new abstractions: rep, and 
cvt. These forms may only be used within a cluster; they are discussed further in Section 1 2.3. 

Within an implementation of an abstraction, formal parameters declared with type can be ueed as type 
specifications. Finally, identifiers that have been equated to type speoMctttom can ate be ueed as type 
specifications. 
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7. Scopes, Declarations, and Equates 

This section describes how to introduce and use constants and variables, and the scope of constant 
and variable names. Scoping units are described first, followed by a discussion of variables, and finally 
constants. 

7.1. Scoping Units 

Scoping units follow the nesting structure of statements. Generally, a scoping unit is a body and an 
associated "heading-. The scoping units are as follows (see Appendix I for details of the syntax). 

1. From the start of a module to its end. 

2. From a duster, proc, Her, equates, guardian, handler, or creator to the matching end. 

3. From a for, do, begin, background, recover, enter, coenter, or seize to the matching 

4. From a then or else in an If statement to the end of the corresponding body. 

5 S2L!LSS L!Sb? ***** *" a te8CMtl ****> Of«^»*»t«t*menttotheendofthe 
corresponding body. 

6. From a when or others in an except statement to the end of the corresponding body. 

7. From the start of a typejset to its end. 

8. From an action or topactton to the end of the corresponding body. 

The structure of scoping units is such that if one scoping unit overlaps another scoping unit (textually), 
then one is fully contained in the other. The contained scope is called a nested scope, and the containing 
scope is called a surrounding scope. 

New constant and variable names may be introduced in a scoping unit. Names for constants are 
introduced by equates, which are syntactically restricted to appear grouped together at or near the 
beginning of scoping units (except in type sets). For example, equates may appear at the beginning of a 
body, but not after any statements in the body. 

In contrast, declarations, which introduce new variables, are allowed wherever statements are allowed, 
and hence may appear throughout a scoping unit. Equates and declarations are discussed in more detail 
in the following two sections. 

in the syntax there are two distinct nonterminals for identifiers: ktn and name. Any identifier introduced 
by an equate or declaration is an ktn, as is the name of the module being defined, and any operations M 
has. An Idn names a specific type or object. The other kind of identifier is a name. A name is generally 
used to refer to a piece of something, and is always used in context; for example, names are used as 
record selectors. The scope rules apply only to kins. 

The scope rules are simple: 
1 . An Idn may not be redefined in its scope. 

2 ' lUiZL !!^,5 )H!£ ^ an extema, re,erence ln a module may not be used for any other 
purpose in tnat module. 
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Unlike other "block-structured" languages, Argus prohibits the redefinition of an identifier in a nested 
scope. An identifier used as an external reference names a module or constant; the reference is resolved 
using the compilation environment. 

7.1.1. Variables 

Objects are the fundamental "things" in the Argus universe; variables are a mechanism for denoting 
(i.e., naming) objects. A variable has three properties: Its type, whether I is stable or not, and the object 
that it currently denotes (if any). A variable is said to be urtnttiaMztd * ft does not denote any object. 
Attempts to use uninitialized variables are programming errors and (if not detected at compse-tlme) cause 
the guardian to crash. 

There are only three things thai can be done with variables: 

1. New variables can be introduced. Declarations perform mis function, and are described 
below. 

2. An object may be assigned to a variable. After an assignment the variable denotes the 
object assigned. 

3. A variable may be used as an expression. The value of a variable is the object that the 
variable denotes at the time the expression is evaluated. 

7.1.2. Declarations 

Declarations introduce new variables. The scops of a variable is from its declaration to the end of the 
smallest scoping unit containing its declaration; hence, variables must be declared before tftey are used. 

There are two sorts of declarations: those wfth initialization, and those without. Simple declarations 
(those without initialization) take the forni 

dec! ::= idn , ... : type_spec 
A simple declaration introduces a list of variables, all having the type given by the typejwe. This typs 
determines the types of objects that can be assigned to the variable. The variables introduced In a simple 
declaration initially denote no objects, i.e., they are uninttafized. 

A declaration with initialization combines declarations and assignments into a single statement. A 
declaration with initialization is entirely equivalent to one or more simple declarations followed by an 
assignment statement. The two forms of d ecla rati on wfth Initialization are: 

tin : type.spec > expression 
and 

decl 1 decl„ > call [ @ primary ] 

These are equivalent to (respectively): 

idn : type_spec 
idn > expression 

and 
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decl, ... decl,, % declaring idn 1 ... idn,,, 

idn 1( ..., idr^ > call [ @ primary ] 
In the second form, the order of the idns in the assignment statement is the same as in the original 
declaration with initialization. (The call must return m objects.) 

7.2. Equates and Constants 

An equate allows an identifier to be used as an abbreviation for a constant, type set, or equate module 
name that may have a lengthy textual representation. An equate also permits a mnemonic identifier to be 
used in place of a frequently used constant, such as a numerical value. We use the term constant in a 
very narrow sense here: constants, in addition to being immutable, must be computable at compMe-time. 
Constants are either types (built-in or user-defined), or objects that are the results of evaluating constant 
expressions. (Constant expressions are defined below.) 

The syntax of equates is: 

equate ::= Idn - constant 
| idn - type_set 
| idn - reference 

constant ::= type_spec 
| expression 

type_set "= { idn | idn has operjjecl , ... { equate } } 

reference I Is idn 

| idn [ actual _parm , ... ] 
| reference $ name 
References can be used to name equate modules. 

An equated identifier may not be used on the left-hand side of an assignment statement. 

The scope of an equated identifier is the smallest scoping unit surrounding the equate defining it; here 
we mean the entire scoping unit, not just the portion after the equate. An the equates in a scoping unit 
must appear grouped near the beginning of the scoping unit. The exact placement of equates depends 
on the containing syntactic construct; usually equates appear at the beginnings of bodies. 

Equates may be in any order within the a scoping unit. Forward references among equates in the 
same scoping unit are allowed, but cyclic dependencies are illegal. For example, 

x-y 
y = z 
z-3 

is a legal sequence of equates, but 
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x-y 
y-z 
z-x 

is not. Since equates tttoduo* ktat, the 

defined more than onoe). 
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8. Assignment and Calls 

The two fundamental activities of Argus programs are calls and assignment of computed objects to 
variables. 

Argus programs should use mutual exclusion or atomic data to synchronize access to aH shared 

variables, because Argus supports concurrency and thus processes can interfere with each other during 

assignments. For example, 

i:-1 
j:-2 

is not equivalent to 

i,j:-1,2 
in the presence of concurrent assignments to the same variables, because any interleaving of indivisible 
events is possible in the presence of concurrency. 

Argus is designed to allow complete compHe-time type-checking. The type of each variable is known 
by the compiler. Furthermore, the type of objects that could result from the evaluation of any expression 
is known at compile time. Hence, every assignment can be checked at compile time to ensure that the 
variable is only assigned objects of its declared type. An assignment v:-£ is legal only If the type of Ete 
included the type of v. The definition of type inclusion is given in Section 6.1. 

8.1. Assignment 

Assignment causes a variable to denote an object. Some assignments are implicitly performed as part 
of the execution of various mechanisms of the language (in exception handling, and the tagcase, tagtest, 
and tagwak statements). All assignments, whether implicit or explicit, are subject to the type inclusion 
rule. 

8.1.1. Simple Assignment 

The simplest form of assignment statement is: 
idn :« expression 
In this case the expression is evaluated, and then the resulting object Is assigned to the variable named 
by the kin in an indivisible event. Thus no other process may observe a "half-assigned" state of the 
variable, but another process may observe various states during the expression evaluation and between 
the evaluation of the expression and the assignment. The expression must return a single object (whose 
type must be included in that of the variable). 

8.1.2. Multiple Assignment 

There are two forms of assignment statement that assign to more than one variable at once: 
idn , ... :■ expression 
and 
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idn , ... :■ caH [ <g> primary ] 

The first form of multiple assignment is a generalization of simpls assignment. The first variable is 
assigned the first expression, the second variable ths second expression, and so on. The expressions 
are all evaluated (from left to right) before any assignments are performed. Ths assignment of multiple 
objects to multiple variables is an indMsfole event, but evaluation of the expressions is divisible from the 
actual assignment. The number of variables in ths list must equal ths nurnos* of expressions, no variable 
may occur more than once, and the type of each variable must Include the type of the corresponding 
expression. 

The second form of multiple assignment allows one to retain the objects resulting from a call returning 
two or more objects. The first variable is assigned the first object, the second variable the second object, 
and so on, but aM the assignments are carried out IndMstxy. The order of the objects is the same as m 
the return statement executed in the called routine. The number of variables must equal the number of 
objects returned, no variable may occur more than once, and the type of each variable must include the 
corresponding return type of the called procedure. 

8.2. Local Calls 

In this section we discuss procedure cads; iterator calls are discussed in Section 10.12. However, 
argument passing is the same for both procedures and iterators. 

Local calls take the form: 
primary ( [ expression ,...]) 

The sequence of activities in performing a local call are as follows: 

1 . The primary is evaluated. 

2. The expressions are evaluated, from left to right. 

3. New variables are introduced corresponding to ths formal arguments of the routine being 
called (i.e., a new environment is created for the called routine to execute in). 

4 The objects resulting from evaluating the expressions (the actual arguments) are assigned 

Z^JZTSZ"^^ The flrtttem* is assigned the 

flrsl tactual, the second formal the second actual, and so on. The type of each expression 
must be included* the type of the conespor^ ^™ MW 

5. Control is transferred to the routine at the start of its body. 

A call is considered legal m exactly those situations where aH the (implicit) assignments are legal. 

A routine may assign an object to a formal argument variable; the effect is just as if that object were 
assigned to any other variable. From the point of view of the cased routine, the only difference between 
its formal argument variables and its other focal variables is that the formate are Initialized by its cafler. 

Procedures can terminate in two ways: they can terminate normally, returning zero or more objects, or 
they can terminate exceptional, signalling an exceptional condition. When a procedure terminates 
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normally, any result objects become available to the cater, andcanlaaaasigriodtovaiiableeorpassedas 
arguments to other routines. When a procedure terminates excep4k>naHy, ttw ftow of control wifl not go to 
the point of return of the cad, but rather wW go to an exception handter (see Section 11). 

8.3. Handler Calls 

As explained in Section 2 and in Section 13, a handler is an operation that belongs to some guardian. 
A handler call causes an activation of the caked harxller to wn at the hoidler* guanSan; tte ^ 
performed at the caned handler's guardian by a new subactJon created solely for this purpose. Usually 
the handler's guardian is not the same as the one in which the caU occurs, and the cased handler's 
guardianislkelytoresiaeatacMeremnotetoto However. It Is legal 

to can a handler that belongs to a guardian residing at the eater's node, or even to caU a handler 
belonging to the caller's guardian. 

Although the form of a handler call looks like a procedure call: 
primary ( [ expression, ... ] ) 
its meaning is very different. Among other things, a handler is cased remotely, witt the argument* and 
results being transmitted by value in messages, and the caU is run as a subactton of its calling action. 
Below we present an overview of what happens when executing a handler caH and then a detailed 
description. 

Aha^ercallrunsasasubactlonofthecaJlingaction. We wtt refer to this subactton as the caU action. 
The first thing done by the call action is the transrrtssiw of me agurrienu of the call. Transmission is 
aeconriplishedbyerx»dingeac^ Thearguments 

are decoded at the called guardian by a subactton of the ctf «xe»i cated the ae*^ ac*m. Each 
argument is decoded by using the ote»* operation of Its type. The effect of transmission is that the 
arguments are passed by value from the cater to the htmter activation: new objects come into existence 
at the handler's guardian that are copies of the aigumsnt objects. Object values are transmitted in such a 
way as to preserve the internal sharing structure of each argume* object is preserved, as wes as any 
sharing structure between the argument objects m a single cal. Set Section 14 for further discussion of 
transmission. 

After the arguments have been transmitted, the activation action performs the handier body. When the 
handler body terminates, by executing a return, abort return, signal, or abort signal statement, the 
result objects are transmitted to the cater by encooang them at the hsndtors guanilan, artoo 
aborting the activation action (as it specified). The caU action then decodes the results at the caters 
guardian. Once the results have been transmitted to the eater, the <* actton cornrnte and execution 
continues in the cater as indicated by the caller's code. (Note that the call action will commit even if the 
activation action aborts.) 



•This is only strict* true for the built-in types. A user-defined type might not preserve intern* sharing structure. 
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8.3.1. Semantics of Handler Calls 

In this section we describe the semantics of a handler call in detail. A handier call causes actMty at 
both the calling guardian and at the called guardian. At the calling guardian, the sequence of activities in 
performing a handier call is as follows: 

1 . The primary is evaluated. 

2. The argument expressions are evaluated from left to right. 

3. A subaction, which we will refer to as the caH action, is created for the remote call. AN 
subsequent activity on behalf of the cal wit be performed by the can action or on* of its 
descendants. For K to be poestte to create the caH action, the eater must already be 
running as an action. Remote caHs by non-actons are pro gr am me errors and cause the 
calling guardian to crash. 

4. A call message is constructed. As part of construe** ft* message, encode operations 
are pertonii^c)n the argument objsete. Nanyef the encode operaHorw terminates with a 
fatfure exception, then the remote cal will terminate wen the same exception, and the call 
action wiH be aborted. 

5. The call message is sent to the guardian of the cased handtor, and the cal action waits for 
the completion of the call. 

6. if the caH message arrives at the node of the target guardian, and the target guardian does 
not exist, then the cal action is aborted with the faUum exception having the string 
"guardian does not exist" as Its exception result. 

7. If ih* system determines that it cannot cc^rmink^ie «^ the ceJM guardian, M ac<^ ^ 
call action. The cal action may be retried several twos (b e g i nn i ng at step 3) In attempts to 
communicate, if rep aa t sd oonwun tea tton tasurea am s n ea unt s rod , the system abortstne 

^""^■fif*??^ The system wH 

pause mis kind of termination only when ft Is extremely unaewn/ that retrying me caH 
immediately wti succeed. 

80^nanty,acalcoir*>leleewhenareplym When 

the raPhrmessage arrives at the caHer, It Is <leco(Jed ueing the oecooe operation tor each 

and the caH terminates with the same exception. Otherwise, the cal action commits. 
9. The call wiH terminate normally if the result message indicates that the hand* activation 
r ti urr lS ( * 8| n,,,,ed >: oHwwtoe » terminates wNh whatever exception was 

At the called guardian, the following activities take place. 

1. A subaction of the call action is created ai the target guardian to run the caN. We wm refer 
to this subaction as the activation action. Al activity at the target guardian occurs on behalf 
of the activation action or one of Its deecendants. 

2. The call message is decomposed into its constituent objects. As part of this process 
decate operations are performed on each argument. N any decode terminates with a 
'-^•xeeptton. wen the activation action is aborted, and tfw <^ temrinates with the same 

3. The catted handier is called within the activation action. This caH is Hke a regular procedure 

0-1 J?!^!?* oWalned ,rom *ced»iO the message are the actual arguments, and they 
aretxxjrxJtotrwfonTMte^implkAassigTiments. 

4 ' H-SL^??^ ¥0*^** ** !* ecuMn » «** return or an abort eigne! statement (see 
Section 11.1), then all committed descendents of the activation action are aborted. Then 
the reply message is constructed by encoding the result objects, the activation action is 
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aborted, and the reply message is sent to the caller. Otherwise, when the handler 
terminates, the reply message is constructed by encoding the result objects, the activation 
action commits, and the reply message is sent to (he caHar. If one of the caHs of encode 
terminates with a failure exception, then the activation action Is aborted, and the call 
terminates with the same exception. 

When the Argus system terminates a call with the unavailable exception, it is posstote that the 
activation action and/or some of its descendants are actually running. This could happen, for example, » 
the network partitions. These running processes are cased "oiphane-. The Argus system makes sure 
that orphans will be aborted before they can view inconsistent data (see Section 2.5). 

8.4. Creator Calls 

Creators are called to cause new guardians to come into existence. As part of the call, the node at 
which the newly created guardian wffl be located may be specified. If the node is not specified, men the 
new guardian is created at the same node as the caller of the creator. The form of a creator can Is: 
primary ([ expression, ... J )[ @ primary J 

The primary following the at-slgn (®) must be of type node. 

A creator call caueee two activities to take place. First, a new guardian ie created at the indicated 
node. Second, the creator ie called as a handler at the newly created guardian. This handler call has 
basically the same semantics as the regular handler can described above. 

The Argus system may also cause a creator cad to abort with the failure or unavailable exceptions. 
The reasons for such terminations are the same as those for handler cats, and the meanings are the 
same: the failure exception means that the can should not be retried, wMe the unavailable exception 
means that the caH should not be retried immediately. 

8.4.1 . Semantics of Creator Calls 

The activities carried out in executing a creator call are as follows. 

1 . The (first) primary is evaluated. 

2. The argument expressions are evaluated from left to right. 

3. The optional primary following the at-sign is evaluated to obtain a node object. If this 
primary is missing, the node at which the call is taking place is used. 

4. A subaction, which we will refer to as the caH acton, ie created. All subsequent activity 
takes iptace wrthin this subaction. As was the case for handtor cats, creators can be called 
only from within actions. A creator caH by a non-action is a programming error and causes 
the calling guardian to crash. 

5. A new guardian is created at the indicated node. The creator obtsiMd to step 1 wi indicate 
the type of thte guardian. The selection of a particular toad image for this type win occur as 
discussed in Section 3.3. -»-«-» 

6. As was the case for handler calls, if the system cannot communicate with the indicated 
node, the creator caH will terminate with the unavailable exception. If the system is unable 
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to determine what implementation to load, or if there is no implementation of the type that 
ZHJZL?!!l I? '"•JS 8 ! 00 *' " " *• m,iM « er <**•**• refuses to allow fie new 

?^?rSS?J!2..^^ reat ^?*J? , ?J sraa i ar cal1 wW ^""*nato wtti ttw «a«ur« exce)ption. in either 
case the call action win be aborted. 

7 'tH!22i 2?J*J£" P?? ™ 1 to ** creator - This can has the same semantics as 
desCTtoedjor handler calls above m steps 4 through 9 of the acthtties at the caMng node 

2!h?!2^ Hwsaw, If either the^acHon 

or the activation action aborts, the newly created guardbn wM be destroyed. 

For example, suppose we execute the creator call 
x: G :- G$create(3) @ n 
where G is a guardian type, n denotes an object of type nods, and create has header 

create - creator (n: int) returns (G) signals (notjroestolefatrtng)) 
The system win select an implementation of G that is suHabie for use at node n, and w«l then create a 
guardian at node n running that implementation. Next create (3) is performed as a handler call at that 
new guardian. If create returns, then the assignment toxwi occur, causing x to refer to the new 
guardian that create returned; now we can caH the handle* provfcled by G. The exception that can be 
signalled by this call are not_posslble, failure, and unavaMabh. An example of a caH that handles all 
these exceptions is: 

x: G > Glcreate (3) <8> n 

except when notjaossible (s: string): ... 
when failure (s: string):... 
whan unavailable (s: string): ... 
and 

Creators are described in more detail in Section 13. 
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9. Expressions 

An expression evaluates to an object In the Argus universe. This object is said to be the result or value 
of the expression. Expressions are used to name the object to which they evaluate. The simplest forms 
of expressions are literals, variables, parameters, equated identifiers, equate module references, 
procedure, iterator, and creator names, and self. These forms directly name their result object. More 
complex expressions are built up out of nested procedure calls. The result of such an expression is the 
value returned by the outermost call. 

9.1. Literals 

Integer, real, character, string, boolean and null literals are expressions. The type of a literal 
expression is the type of the object named by the literal. For example, true is of type boot, "abc" is of 
type string, etc. (see the end of Appendix I for details). 

9.2. Variables 

Variables are identifiers that denote objects of a given type. The type of a variable is the type given in 
the declaration of that variable. An attempt to use an uninitialized variable as an expression is a 
programming error and causes the guardian to crash. 

9.3. Parameters 

Parameters are identifiers that denote constants supplied when a parameterized module is instantiated 
(see Section 12.5). The type ol a parameter is the type given in the declaration of mat parameter. Type 
parameters cannot be used as expressions. 

9.4. Equated Identifiers 

Equated identifiers denote constants. The type of an equated identifier is the type of the constant 
which it denotes. Identifiers equated to types, type_sets, and equate modules cannot be used as 
expressions. 

9.5. Equate Module References 

Equate modules provide a named set of equates (see Section 12.4). To use a name defined in an 
equate module as an expression, one writes: 

reference $ name 
where 

reference ::= idn 

| idn[ actual jsarm,...] 
| reference $ name 
The type of a reference is the type of the constant which it denotes, identifiers equated to types, 
type_sets, and equate modules cannot be used as expressions. 



9.8 Bind jg 

The evaluation of a bind expression proceeds by first evaluating the entity and then evaluating, from 
left to right, any btod_jugs that are expressions. The entity may evaluate to a procedure, iterator, 
handler, or creator object. Suppose that the entity is a procedure or Iterator object. (Creator and handler 
bindings are discussed below.) Then the result is formed by binding the argument objects to the 
corresponding formate of the entity to form a closure; note mat the procedure or iterator is not called when 
the bind expression is evaluated. When the closure is called, the object denoted by the entity is passed 
all the bound objects and any actual arguments supplied in the caH, aH in the corresponding argument 
positions. 

For example, suppose we have: 
p - proc(x: T, y: Int, w: S) returns^) slgnals<too_Wg) 
Then 

q> bind pC, 3 + 4,*) 
produces a procedure whose type is prectype<r, S) retums(fl) stgnals<tooJ*&) and assigns it to q. A 
call of q(a, ti) is then equivalent to the caH p(a, 7, ti). 

Bound routines wiH be stored m stable storage If they are acossstXe from a stable variable (see 
Section 13.1). In mis case the entity and the bind_args should denote atomic objecto. 

There is only one instance of a routine's own data for each parametorizatkm; thus aN the bindings of a 
routine share its own data, If any (see Section 12.7). Each binding is generally a new object; thus the 
relevant equal operation may treat syntactically Identical bindings as distinct. 

The semantics of binding a creator or handler are similar to binding a procedure or iterator; the 
differences arise from argument transmission. Encoding of bound argument objects happens when the 
bind expression is evaluated and sharing is only preserved among objects bound at the same time (see 
Section 14). In more detail, the evaluation of a bind expression proceeds by first evaluating the entity 
and then evaluating, from left to right, any bind_a/gs mat are expressions. Then the argument objects 
are encoded, from left to right, preserving sharing among these objects. The result is formed by binding 
theeixxxtedaj^inertobjectetotheconespond^ Notethatthe 

entity is not called when the bind expression is evaluated. 

When the closure is called, first any other arguments are evaluated and encoded (not sharing with the 
bound objects) and then the caH to the entity is initiated. Decoding of the arguments at the called 
guardian is done in reverse of the order of encoding; that is, other arguments are decoded before bound 
arguments and the most recently bound arguments are decoded first. Sharing is preserved on decoding 
only among groups of bound arguments and among the other arguments, not between groups. 
Thereafter the call proceeds as normally. 

For example, if we execute 

hi :- bind h(x, y, •) 
h1(z) 
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then sharing of objects between x and y win be preserved by transmission, but sharing wiH not be 
preserved between x and z or y and z. 

Closures can be used in equates, provided aH the expressions are constants (see Section 7.2.2). 
However, a handler cannot appear in an equate, since it is not a constant. 

9.9. Procedure Calls 

Procedure caHs have the form: 
primary ( [ expression ,...]) 
The primary is evaluated to obtain a procedure objsct, aiid then tt» expiisstons are evaluated left to rtgW 
to obtain the argument objects. The procedure is called with these arguments, and the object returned is 
the result of the entire expression. For more discussion see Section 8. 

Any procedure caH p(E 1 ,...E^ must satisfy two constraJnts to be used as an expression: the type of p 
must be of the form: 

P»octyP« (T, T„) returns (R) signals (...) 

and the type of each expression E, must be included in the corresponding type 7). The type of the entire 
call expression is given by ft 

9.10. Handler Calls 

Handler caHs have the form: 

primary ( [ expression, ... ] ) 
The primary is evaluated to obtain a handler object, and then tne expressions are evaluated left to right to 
obtain the argument objects. The handler is then cased w*h these arguments as discussed in Section 
8.3. The following expressions are examples of handler cats: 

h(x) 

Wojguard.whojs userfjohn", "doe") 

dowjonss.lnforx7z Corporation-) 

Any handler caH h(E v ... EJ must satisfy the following constraints when used as an expression The 
type of h must be of the form: 

htndleitype (T 1( ... T n ) returns (R) signals (...) 

and the type of each expression ^must be included In the corresponding type 7j. The type of the entire 
call expression is given by ft 

As exptained in Ssction 8.3. the execute ^ Jtmtion 

an attempt io caH a handler from a pnxeas t^ ^ 

cause the calling guardian to crash. This crash occurs after afl of me consonant expressions have been 
evaluated. 
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9.11 Creator Calls 

9.11. Creator Calls 

Creator cans have the form: 
primary ([ expression, ... ]) [©primary] 
The first primal evaluated to obtain a creator object, the argument expressions are evaluated left to 
right to obtain the argument objects, and then the primary tofewlng the at-sign (®), v present, is 
evaluated to obtain a node object If the primary fosowkig the at-sign it omitted, then node$/wfe() is 
used. The guardian is then created at that node, and the creator <saled. as dtocussed in Section 8.4. The 
following are examples of creator cafe: 

mater$create() <& n 
8pooleifdevtypeJ$create{) 

A creator can cfE, EJ0n must satisfy the following constraints when used as an expression. The 

type of c must be of the form: 

cwaortyptCT, Tjrsturnt(R) signals <...) 

where each 7j includes the type of the conesponding expression 5. N must be of type node. Thetype 
of the entire can expression is given by R. 

As with handler cafe, an attempt to call a creator from a process that is not running an action will cause 
the calling guardian to crash after aJ component expressions have been evaluated. 

9.12. Selection Operations 

Selection operations provide access to the individual eiernenfe or oomjmnenforf ^ simple 

rttattons are provided for <je*^ ths ^ 

Hketypes. In addition, these -syntactic sugaring*- for selection (ipsfatiom it«ay be used for user-defined 
typas with the appropriate properties. 

9.12.1. Elomont Sanction 

An element seisction expression has the form: 
primary [ expression ] 

This form is just syntactic sugar for a call of a fetch cip*n«ion. sjid Is computali(>na«y «|uivafont to: 

T$feteh<primary, expression) 
where T is the type of the primary. T must provide a procedure operation named fafon. which takes two 
argurnems whose types include the types of prtrna^ 

9.12.2. Component Sarectlon 

The component selection expression has the form: 

primary, name 

This form is just syntactic sugar for a call of a gername operation, and is computationally equivalent to: 
T$get_name<primary) 

where T is the type of primary. T must provide a procedure operation named get_name, that takes one 
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argument and returns a single result. Of course, the type of the procedure's argument must Include the 
type of the primary. 

9.13. Constructors 

Constructors are expressions that enable users to create and initialize sequences, arrays, atomic 
arrays, structures, records, and atomic records. There are no constructors tor user-defined types. 

9.13.1. Sequence Constructors 

A sequence constructor has the form: 
type_spec$ { [ expression ,...]] 
The typejapec must name a sequence type: seq u e n cer./]. This is the type of the constructed sequence. 
The expressions are evaluated to obtain the elements of the sequence. They correspond (left to right) to 
the indexes 1 , 2, 3, etc. For a sequence of type eequence(7], the type of each element expression in the 
constructor must be included m T. 

A sequence constructor Is computationally equivalent to a sequence new operation, followed by a 
number of sequence addh operations. 

9.13.2. Array end Atomic Array Constructors 

An array or atomic array constructor has the form: 
type.spec $[[ expression :][ expression ,...] ] 
The />pe_spec trust name an array or atomteaT^ This is the type of 

the constructed array. The optional expression preceding the coton (:) must evaluate to an integer, and 
becomes the tow bound of the constructed array or atomic array. If this expression is omitted, the tow 
bound is 1. The optional list of expressions is evaluated to obtain the elements of the array. These 
expressions correspond (left to right) to the indexes kmjbound, bwjbound+l . tow_bound+2, etc. For an 
array or atomic array of type arrayfT] or atomlc_arraytT], the type of each element expression in the 
constructor must be included In T. A constructor of the form arrayf.7]$r] has a tow bound of 1 and no 
elements. 

An array constructor is computationally equivalent to a create operation, followed by a number of addh 
operations. 

9.13.3. Structure, Record, and Atomic Record Constructors 

A structure, record, or atomic record constructor has the form: 
type_spec ${ field ,... } 
where 

field ::= name , ... : expression 
Whenever a field has more than one name, it is equivalent to a sequence of fields, one for each name. 
ThuMff-racoitila: mt,b: lnt,c: Int J, then the following two constructors are equivalent: 



9.13.3 Structure, Record, and Atomic Record Constructor* 53 

R${a,b:pO, c:9} 
R${a:p(), b:pO, c:9} 

In the following we discuss only record constructors; structure and atomic record constructors are 

similar. In a record constructor, the type specification must name a record type: rtcoid[S,:r, S n .TJ. 

This is the type of the constructed record. The oomponent names in the field list must be exactly the 
names S 1t .... S„, although these names may appear In any order. The expressions are evaluated left to 
right, and there is one evaluation per component name even N several component names are grouped 
with the same expression. The type of the expression for component S, must be included m T t The 
results of these evaluations form the components of a newly constructed record. This record is the value 
of the entire constructor expression. 

9.14. Prefix and Infix Operators 

Argus allows prefix and infix notation to be used as a shorthand for the operations listed in Table 9-1 . 
The table shows the shorthand form and the computational equivalent expanded form for each 
operation. For each operation, the type T is the type of the first operand. 

Table 9-1: Prefix and Infix Operators: shorthands and expansions 



Shorthand form Expansion 

expr, - expr 2 TSpowertexpr,, expr 2 ) 

expr, //expr 2 Tlmodtexpn, expr 2 ) 

expr^exp^ T$dJv(expr 1 , expr 2 ) 

expr, * expr 2 T$mul(expr t , expr.) 

expri || expr 2 T$concat(ej(pr t , expr.) 

expr, + expr 2 T*add(cxpr,, expr,) 

expr, - expr 2 T$eub(expr,, expr.) 

expr,<expr 2 T**(expf,, expr.) 

expr 1 <- expr 2 T$le<expr,, expr.) 

expr, - expr 2 TIaquaxexpr,, expr 2 ) 

expr, >- expr 2 T$ge<ex|>r„ expr^ 

expr,>expr 2 T*gt<expr,, expr 2 ) 

expr, ~< expr 2 « (expri K expr2 ) 

exDr i ~ <m ex P f 2 - (expr, <- expr.) 

expr,~-expr 2 ~ (expr, - expr/ 

exDr i ->" ex P r 2 - (expr, >- expr.) 

expr,~>expr 2 - (txpr, > expr/ 

expr, & «xpr 2 T$and(expr, , txpr 2 ) 

expr, | expr 2 T$or(expr,, expr 2 ) 

- ex P f T$miiius(expr) 

~ exDr T$not(expr) 



Operator notation is used most heavily tor the built-in types, but may be used for user-defined types as 
well. When these operations are provided for user-defined types, they should be free of side-effects, and 
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they should mean roughly the same thing as they do tor the built-in types. For example, the comparison 
operations should only be used for types that have a natural partial or total order. Usually, the 
comparison operations (ft to, equal, ge,gt> win be of type 

proctype (T, T) returns (boot) 
the other binary operations (e.g., add, sub) wW be of type 

proctype (T, T) returns (7) signals (...) 
and the unary operations win be of type 

proctype (T) returns (T) signets (...) 

9.15. Cand and Cor 

Two additional binary operators are provided. These are ths conditional and operator, cand, and the 
conditional or operator, cor. The result of evaluating: 

expression, cand expression 
is ths boolean and of expression, and expression^ However, If expression, is false, expressions is 
never evaluated. The result of evaluating: 

expression, cor expression 
is ths boolean or of expression, and expressions, but expressions is not evaluated unless expression, is 
false. For both cand and cor, expression, and expressions must have type boot. 

Because of the conditional expression evaluation involved, uses of cand and cor are not equivalent to 
any procedure call. 

9.16. Precedence 

When an expression is not tolly parenthesized, the proper nesting of subexpressions might be 
ambiguous. The following precedence rules are used to resolve such ambiguity. The precedence of 
each infix operator is given in the table below. Higher precedence operations are performed first. Prefix 
operators always have precedence over infix operators. 

Table 9-2: Precedence tor Infix Operators 



Precedence Operators 

5 ** 

4 * / // 

3 + - II 



2 
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1 & cand 

| cor 



9.16 Precedence 

The order of evaluation for operators of the same precedence is left to right, except for ", which is right 
to left. 

9.17. Up and Down 

There are no implicit type conversions in Argus. Two forms of expression exist for explicit conversions 
These are: 

up ( expression ) 
down ( expression ) 

Up and down may be used only within the body of a duster operation (see Section 12.3). Up changes 
the type of the expression from the representation type of the cJut* to the abstract type. Down converts 
the typs of the expression from the abstract type to the representation type. 
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10.2. Update Statements 

Two special statements are provided for updating components of record and array-Hke objects. In 
addition they may be used with user-defined types with the appropriate properties. These statements 
resemble assignments syntactically, but are actually call statements. 

10.2.1. Element Update 

The element update statement has the form: 

primary [ expression ] :- expressk>n 2 
This form is merely syntactic sugar for a caH of a store operation; it is equivalent to the caU statement : 

T$store(primary, expression, , expression^ 
where T is the type of the primary. T must provide a procedure named stow that takes three arguments 
whose types include those of primary, expression,, and expression? respectively. 

10.2.2. Component Update 

The component update statement has the form: 

primary . name :- expression 
This form is syntactic sugar for a caH of a set_ operation whose name is formed by attaching sef_ to the 
name given. For example, if the name is f, then the statement above is equivalent to the caH statement: 

T$8et J(primary, expression) 
where T is the type of the primary. 7 must provide a procedure operation named setj, where /is the 
name given in the component update statement. This procedure must take two arguments whose types 
include the types of primary and expression, respectively. 

10.3. Block Statement 

The block statement permits a sequence of statements to be grouped together into a single statement. 
Its form is: 

begin body end 
Since the syntax already permits bodies inside control statements, the main use of the block statement is 
to group statements together for use with the except statement (see Section 11). 

10.4. Fork Statement 

A fork statement creates an autonomous process. The fork statement has the form: 
fork primary ( [ expression, ... ] ) 
where the primary is a procedure object whose type has no results or signals (see Section 12.1). The 
type of each actual expression must be included in the type of the corresponding formal. 

Execution of the fork statement starts by evaluating the primary and actual argument expressions from 
left to right. Any exceptions raised by the evaluation of the primary or the expressions are raised by the 
fork statement. If no exceptions are raised, then a new process is created and execution resumes after 
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the fork statement in the old process. The new process starts by calling the given procedure with the 
argument objects. This new process terminates N and when the procedure call does. However, if the 
guardian crashes the process goes away (Hke any other process). 

Note that the new process does not run in an action, although the procedure called can start a 
topactton if desired. There is no mechanism for watting for the termination of the new process. The 
procedure catted m a fork statement cannot return any result* or signal any exceptions. 

10.5. Enter Statement 

Sequential actions are created by means of the enter statement which has two forms: 

enter topactton body end 
and 

enter action body end 
The topactton qualifier causes the body to execute as a new top-level action. The action qualifier 
causes the body to execute as a subactton of the current action; an attempt to execute an enter action 
statement in a process that is not executing an action is a programming enw ai^ cauaes trie guardian to 
crash. When the body terminates, It does so either by oommlNng or aborting. Normal completion of the 
body results In the action committing. Statements that transfer control out of the enter statment (exit, 
leave, break, continue, return, signal, and raafgnal) normaNy commit the action unless are prefixed 
with abort (e.g., abort exit). Two-phase commit of a topactton may fail, in which case the enter 
topactton statement raises an unavailable exception. 

10.6. Coenter Statement 

Concurrent actions and processes are created by means of the coenter statement: 
coenter coarm { coarm } end 
where 

coarm ::s armtag [ foraach decl .... In call ] 
body 

armtag ::= action 
| topactton 
| process 

Execution of the coenter starts by creating all of the coarm processes, sequentially, In textual order. A 
toreach clause indicates that multiple instances of the coarm will be created. The can in a foraach 
clause must be an Iterator call. At each yield of the Iterator, a new coarm process is created and the 
objects yielded are assigned to newly declared variables In that piooses. (This implicit assignment must 
be legal, see Section 6.1.) Each coarm process has separate, local instances of the variables declared in 
the foraach clause. 
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The process executing the coenter is suspended until after the coenter is finished. Once ail coarm 
processes are created, they are started simuftaneously as concurrent sUinos. Each coarm instance runs 
in a separate process, and each coarm with an armtag of topectton or action executes within a new 
top-level action or subaction, respectively. Anattcnipttoexecutoaeointif w1mapi«*» 
in an action, or to execute a coenter with an action coarm when not in an action Is an error and will 
cause the guardian to crash (see Table 10-1). 

Table 10-1: Legality of coenter statements. 



armta Q not in an action 



process executing the coenter is: 



running an action 



■ctton not legal too* 

topactlon le ^ | JJJ 

P~ces. legal Slegai 



A simple example making use of foreach is: 

coenter action foreach i: Int In mt$from to (1 , 5) 
PC) 
end 

which creates five processes, each with a local variable /, having the value 1 in the first process, 2 in the 
second process, and so on. Each process runs in a newly created subaction. This statement is legal 
only if the process executing it is running an action. 

A coarm may terminate without terminating the entire coenter (and sibling coarms) either by normal 
completion of its body, or by executing a leave statement (see Section 10.7). The commit of a coarm 
oectaredasatopectionmaytemiin^ ^ m 

exception can only be iianded outsi* the coerter « 
coenter (as explained below). 

A coarm may also terminate by transferring control outside the coenter statement. When such a 
transfer of control occurs, the following steps take place. 

which point the coarm becomes the conirolUng coarm. 

2 * SSUiUJ^tn 2S K ? Mno ooarm ' 9 ?P **** ac * lw coarm "■ *» terminated (and abort if 

3 '2l^'^ii , !!I m J wn "TS 8 w • bort8 " *"***«* " •" "*"J if declared as a 

^SatemerT "*■ """^ term,na,e8 ' and cortro ' ,to * oorthuM outside the coenter 

Divisible termination implies, for instance, that a nested topaction may commit whHe its parent action 
aborts. 
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A simple example of early termination is reading from a repHcated database, where any copy can 

supply the necessary information: 

coenter action foretell db: database m afljepHcas (...) 
return( database$read (db)) 
end 

When one of these coarms completes first, it tries to commit itself and abort the others. The aborts take 

place immediately (since there are no seize statements); M is not necessary for the handler cads to finish. 

it is possible that some descendants of an aborted coarm may be njoning at remote sites when the coarm 

aborts; the Argus system ensures that such orphans wit be aborted before they can make their presence 

known or detect that they are in fact orphans (see Section 2.5). 

10.7. Leave Statement 

The leave statement has the form: 
[abort] leave 
Executing a leave statement terminates the innermost enter statement or coenter coarm in which it 
appears. If the process terminated is an action, then it commits unless the abort qualifier is present, in 
which case the action aborts. The abort qualifier can only be used textuaHy wHNn an enter statement or 
within an action or topaction coarm of a coenter statement. 

Note that unUke the other control flow statements, leave does not affect concurrent sbNngs in a 
coenter (see Section 10.6). 

10.8. Return Statement 

The form of the return statement is: 
[abort] latum [(expression,...)] 
The return statement terminates execution of the containing routine. If the return statement occurs in an 
Iterator no results can be returned. If the latum statement is in a procedure, handler, or creator the type 
of each expression must be included in the comjspondlng return type of the routine. The e**»*atons (if 
any) are evaluated from left to right, and the objects obtained 

If no abort qualifier is present, then aH containing actions (* any) terminated by mis statement are 
committed. If the abort qua* tor is present, then ad terminated actions are aborted. Note mat unHke the 
leave statement, return win abort concurrent sbNngs if executed within a coarm of a coenter statement 
(see Section 10.6). The abort quaNfler can onty be used textuaHy within an enter statement, an action or 
topaction coarm of a coenter statement, or the body of a handler or creator. 

Within a handier or creator, the result objects are encoded just before the activation action terminates, 
but after all control flow and nested action termination, if encoding of any result object terminates in a 
Mure exception, then the activation action aborts and the handler or creator terminates with the same 
exception. 
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10.9. Yield Statement 

The form of a yield statement is: 
yield [ ( expression ,...)] 
The yield statement may occur only in the body of an Iterator. The effect of a yield statement is to 
suspend execution of the iterator invocation, and return control to the caflng for statement or foreech 
clause. The values ot*a*«d by walua*io the «^^ 

The type of each expression must be included in the eoneepondtog yield type of the iterator. Upon 
resumption, execution of the iterator continues at the steienient feftowlng the yttd statement. 

A yield statement cannot appear textuady inside an enter, coenter, or eetze statement. 

10.10. Conditional Statement 

The form of the conditional statement is: 
If expression then body 
{ elsetf expression then body } 
[else body] 
end 

The expressions must be of type boot. They are evaluated successively until one is found to be two. 
The body corresponding to the first true expression is executed, and the execution of the H statement 
then terminates. If there is an else clause and If none of the expmskm is true, then the body in the 
else clause is executed. 

10.11. While Statement 

The while statement has the form: 
while expression do body end 
Its effect is to repeatedly execute the body as long as the expression remains true. The expression must 
beoftypebool. If the value of the expression is true, the body is executed, and then the entire while 
statement is executed again. When the expression evaluates to false, execution of the wMIe statement 
terminates. 

10.12. For Statement 

An Iterator (see Section 12.2) can be called by a for statement. The Iterator produces a sequence of 
towns (where an Hem is a group of zero or more objects) one ft^ at a time; the 6oo> of the for statement 
is executed for each Item in the sequence. 

The for statement has the form: 

for [ dec! ,...] In call do body end 

or 

for [ kjn , ... ] m call do body end 
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The can must be an iterator call. The second form (with an km Hst) uses distinct, previously declared 
variables to serve as the loop variables, whitethefin«form(wlmactec* list) form introduces new 
variables, local to the for statement, for this purpose. In either case, the type of each variable must 
Include the corresponding yield type of the (sailed Iterator (see Seclton 12.2) and the nuntoer of variant 
must also match the yield type. 

Execution of the for statement begins by calling the iterator, which either yields an item or terminates. 
If It yields an item (by executing a yteW statement), ks txecoicm is tofipwailiy suspencled. the objects in 
the item are assigned to the loop variables, and the body of the tor statement is executed. The next 
cycle of the loop is begun by resuming execution of the Iterator after the yteW statement which 
suspended it. Whenever the iterator terminates, the entire tor statement terminates. 

10.13. Break and Continue Statements 

The break statement has the form: 
[abort] break 
Its effect is to terminate execution of the smallest tor or white loop statement in which it appears. 
Execution continues with the statement following that bop. 

The continue statement has the form: 
[ abort ] continue 
Its eff ect is to start the next cycle (if any) of the smallest tor or white Icop statement in which it appears. 

Terminating a cyde of a locpnwy also ter^ If no abort qualifier 

is present, then all these terminated actions (if any) are committed. If the abort qualifier is present, then 
all of the terminated actions are aborted. UnNke leave, break and continue wiH abort concurrent suing 
actions when control flow leaves a containing coenter (see Section 10.6). 

The abort qualifier can only be used textually within an enter statement or an action or topactlon 
coarm of a coenter statement. 

10.14. Tagcase Statement 

The ts«caa* statement can be used to ctecorriaoM variant objects 

can be decomposed with the tagteet or tagwaN statements. The clecomposition is indivi&tole tor variant 
objects; thus, use of the tagcase statement for variants is not equivalent to using a conditional statement 
in combination with fe_ and va/ue_ operations (see Section 11.15). 

The form of the tagcase statement is: 
tagcase expression 
tag_arm { tag_arm } 
[others: body] 
end 
where 
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tag_arm ::s tag name , ...[( idn: type_spec )]: body 
The expression must evaluate to a onaof or vartant object. The tag of this object is then matched 
against the names on the tag^arme. When a match is found, if a declaration (kkr. typejspeQ exists, the 
value component of the object is assigned to the new local variable kki. The matching body is then 
executed; idn is defined only in that body. If no match is found, the ftooy in the others arm is executed. 

In a syntactically correct tagcase statement, the following three constraints are satisfied. 

1. The type of the express^ rnust be some oneof or variant type, T. 

2. The tags named in the tagjarms must be a subset of the tags of T, and no tag may occur 
more than once. 

3. If all tags of T are present, there is no others arm; otherwise an others arm must be 
present. 

On any tag_arm containing a declaration (kin: type_spec), type_apec must include the type/s) of T 
corresponding to the tag or tags named to that tag_arm. 

10.15. Tagtest and Tagwait Statements 

The tagtest and tagwait statements are provided for decomposing atomlc_vartant objects, permitting 
the selection of a body based on the tag of the object to be made ino^istoty with the testing or aoquisNton 
of specified locks. 

10.15.1. Tagtest Statement 

The form of the tagtest statement is: 
tagtest expression 
atag_arm { atag_arm } 
[others: body] 
and 
where 

atag_arm ::= tag_ktod name ,...[( idn: type_spec ) ] : body 

tag_kind "stag 
|wtag 
The expression must evaluate to an atomlc_vartant object. If a read tock could be obtained on the 
atomte_vartant object by the current action, then the tag of the object Is matched against the names on 
the aav_amw; otherwise the others arm, if present, is executed. If a matching name is found, then the 
tagjdnd is considered. 

• If the tagjdnd is tag, a read lock is obtained on the object and the match is complete. 

• If the tag khd\s wtag and the current action can obtain a write tock on the object, then a 
write tock is obtained and the match is complete. ^^ 

When a complete match is found, If a declaration (Idn: ft*»_spec) exists, the value component of the 
object is assigned to the new local variable Idn. The matching body is then executed; idn is defined only 
in that body. The entire matching process, including testing and acquisition of locks, is indivisible. 
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If a complete match is not found, or the object was not readable by the action, then the others arm (if 
any) is executed; » there is no others arm, the tagteet statement terminates. If no complete match is 
found, then no locks are acquired. 

The tagtest statement wW only obtain a lock if it is possible to do so without "waiting-. For example, 
suppose that the internal state of the atomlc_vai1ant indicates that some previous action acquired a 
conflicting lock. This action may have since aborted, or may have committed up to an ancestor of the 
action executing the tagteet, but determining such facts may require system-level communication to other 
guardians. In this case the tagteet statement may give misleading information, because it may not 
indicate a match. Apparent anomalies In testing locks may occur even if the action executing the tagtest 
"knows" that the lock can be acquired, so that the use of tagteet to avoid deadlocks or long delays may 
result in excessive aborts. 

10.15.2. Tagwalt Statement 

The form of the tagwalt statement is: 
tagwatt expression 
atag_arm { atag_arm } 
end 
Execution of the tagwalt statement proceeds as for the tagteet statement, but if no complete match is 
found, or If the object is not readable by the current action, then the entire matching process is repeated 
(after a system-controUed delay), until a complete match Is found. Although there is no others arm in a 
tagwalt statement, all tag names do not have to be feted. 

10.15.3. Common Constraints 

Tagteet and tagwalt statements may be executed only within an action. An attempt to execute a 
tagtest or tagwatt statement in a process that is not executing an action is an error and will cause the 
guardian to crash after evaluating the expression. 

In a syntactically correct tagteet or tagwalt statement, the following three constraints are satisfied. 

1. The type erf the expresstonniist be some atomlc_vartant type, T. 

2. The tags named in the atagjarms must be a subset of ths tags of T, and no tag may occur 
more than once. 

3. Finally, on any atagjarm containing a declaration (A*r. type sped), type spec must include 
the type(s) specified as corresponding in Tto ths tag or tagsliamed in the atag_arm. 

A simple example of a tagteet statement is garbage cosseting the elements of an array that are in the 
dequeued state: 
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10.18. Terminate Statement 

The terminate statement may occur only within a guardian deftnMon (tee Sect 13). The term of a 
terminate statement Is: 

terminate 
When executed within an action, to effect is to cause the evertual destnjctton of the guardian after the 
enclosino action commto to the top. N a process attempts to execute terminate white not mm** an 
action, a topactton is created to execute the tormina* and bnmediole* commit. 



L^t^betheaottonthatleexecUir)0thelMiiilnato. The effort erf thwetatermf* Is tnefottowing: 
1. Acton a n™*^ .^«k- ~*~>»- — t-rtifTT tpiMlton H rwmrtisiJ matin >u 1 In 
J^ZZ * 9*****9**m whose cmabon hee eafemmed to me top mete wl be no 
wat, but tor a ro oe nrty c rea ted y Manaan mm may be a detoy. ■ 
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time may proceed to the next step. 

If some ancestor of A aborts, however, the gucrtton wfl be tmc*K*sd. TfceauM**n is 
also unaffeotod during the tone between 4 exact** toowmato and 4 c*mm£ngVtf>e 



In oner to avoid serialization prebiems. cwtabon or dsctnjcfen of a guardian must be synchronized 
with use of that guardian via atomic objects eueh as the cetatog (see Section 3.4). 
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1 1 . Exception Handling and Exits 

A routine is designed to perform a certain task. However, in some cases that task may be impossible 
to perform. In such a case, instead of returning normally (which would imply successful performance of 
the intended task), the routine should notify its caller by •Hin^^m\9xC0plk>n,cons\B^ O la(iesa^i,B 
name and zero or more result objects. 

The exception handling mechanism consists of two parts: signalling exceptions and handling 
exceptions. Signalling is the way a routine notifies its caller of an exceptional condition; handling is the 
way the caller responds to such notification. A signalled exception always goes to the immediate caller, 
and the exception must be handled in that caller. When a routine signals an exception, the current 
activation of that routine terminates and the conesponolngcal (In ftectf^ is said to /»to the exception 
When a can raises an exception, control immediately transfers to the closest applicable exception 
handler. Exception handlers are attached to statements; when execution of the exception handler 
completes, control passes to the statement !o**ir* »» or* to whfc* ^ 
For brevity, exceiton nandlere wW be c^ 
the remote can handlers of guardians (see Section 13). 

11.1. Signal Statement 

An exception is signaled with a signal statement, which has the form: 
[ short ] signal name [(expression,...)] 
Aagnrtstatsmsrtrnayapjjearanywhsre^ Tits exsciition of a signal statement 

begins with evaluation of the expressions (If any), f «oro Wl to right to piodwa a list of ewape^ 
The activation of the routine is then terminated. Execution continues m the osier as described In Section 
11.2 below. 

The exception name must be one of the exception names listed m the routine heading. If the 
corresponding exception specification in the heading has the term: 
nameO", T„) 

then there must be exactly n expressions in the signal statement, and the type of the An expression must 
be included in 7j. 

If no abort qualifier is present, then all containing actions (if any) terminated by this statement are 
commrtted. If the abort qualifier is present, then alt terminated actton. »e aborted. Unlike the leave 
statement, signal win terminate (abort) concurrent sDHnge N executed within a coenter statement (see 
Section 10.6). Ths abort quaWisr can only bs used textuaky wM* a* enter statomert, a* action or 
topactlon coarm of a coenter statement, or the body of a handter or creator. 

Within a handler or creator, the result objects are mMm*^*m*m»mM»*mtn*m, 
but after termination ofaH control flc* art nested actions. If snoeolng of any rest* object terminates in a 
failure exception, then the activation action aborts and tha riaridler or creator tem*urtes ^ 
exception. 
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11.2. Except Statement 

When a routine activation terminates by signalling an axcaptton, tha called routine it said to rafca that 
exception. By attaching exception handlers to statements, the (Jaltf <^ spedfy the action to be taken 
when an exception is raised by a can within a statement or by the statement Used. 

A statements handlers attached is called an except statement, and has the form: 
statement except { when Jiandler } 
[others.handler] 
and 

where 

when_handler ::= whan name. ... [(decl ,...)]: body 
| whan name ,...(*): body 

others.handler ::= others [ ( idn : string ) ] : body 
Let S be the statement to which the handlers are attached, and let Xbe the entire except statement 
Each when_handler specifies one or more exception names and a body. The body is executed if an 
exception with one of those names is raised by a call in 5. Each of the names listed in the 
when__handlers must be distinct. The optional o*e*Jiandter is used to handle al exceptions not 
explicitly named in the when_handlem. The statement Scan be any torn, of statement, andcanevenbe 
another except statement As an example, consider the following except statement: 
m,send_maU(user, myjnessage) 

except when nonsuch user: ... % body 1 

when unavailable, failure (s: string): ... % body 2 
when others (ename: string): ... % body 3 
end 

This statement handles exceptions arising from a remote cad. If the call raises a nonsuch user 
exception, then DodyrwBI be executed. If the caH raises a faHum or unavailable exception, then "body 
2" wiH be executed. Any other exception wW be handled by TxxJy 3." 

If, during the execution of S, some call in S raises an exceiation £, <x>ntrol trailers to ttw textually 
closest handler for E that is attached to a statenwnt cortaWng the call. When execution of the handler 
completes, control passes to the statement following the one to wra^ the harxaer is sIumx^ Tnusifthe 
closest handler is attached to S, the statemem following X is executed next. If execution of S completes 
without raising an exception, the attached handlers are not executed. 

An exception raised inside a handler is treated the same as any other exception: control passes to the 
closest handler for that exception. Note that an exception raJeed m eoinehaiidler attached to S cannot be 
handled by any handler attached to S; the exception can be hanesed wHNn tiie handler, or It can be 
handled by some handier attached to a statement containing X. For example, in the following except 
statement: r 
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times3_plu8l(a) 

except when limits: 

a > a + a 
when overflow: ... % body 2 
end 

any overflow signal raised by the expression a + a WW not be handled in "body 2," because this overflow 
handler is not in an except statement attached to the assignment statement a :«a + a. 

We now consider the forms of exception handlers in more detail. Thetorm: 
when name ,...[( decl ,...)] : body 
is used to handle exceptions with the given names when the exception results are of interest. The 
optional declared variables, which are local to the handler, are assigned the exception results before the 
body Is executed. Every exception potential handled by this fomt (rust he^ the saim niirnber of results 
as there are declared variables, and the types of the variables rrxist kicluo^ the types of the resufts. The 
form: 

when name ,».(*): body 
handles all exceptions with the given names, regardless of whether or not there are exception results; any 
actual results are discarded. Using this torni, exceptions with offering numbers and types of results can 
be handled together. 

Thetorm: 
othert [ ( idn : string ) ] : body 
is optional, and must appear last In a handler list. This form handles any exception not handled by other 
handlers in the list. If a variable is declared, it must be of type etrtng. The variable, which is local to the 
handler, is assigned a lower case string representing the actual exception name; any reeuNs are 
discarded. 

Note that number and type of exception results are ignored when matching exceptions to handlers; 
only the names of exceptions are used. Thus the following is HIegal, in that intfcfr signals zero_dlvide 
without any results (see Section II.4), but the closest handler has a declared variable: 
begin 

y: Int > 
x:lht:-3/y 

except when zero_cMvide (z: Int): return end 
end 
except when zero_drvide: return end 

A call need not be surrounded by except statements that handle aN potential exceptions. In many 
cases the programmer can prove that a particular exception will not arise; for example, the call 
lnt$oMx, 7) win never signal zerojMvide. However, if some call raises an exception tor which there is no 
handler, then the guardian crashes due to this error . 
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1 1 .3. Resignal Statement 

A resigns! statement is a syntactically abbreviated form of exception handling: 

statement [ abort ] reslgnsl name , ... 
Each name listed must be distinct, and each must be ons of the condition names listed in the routine 
heading. The resigns! statement acts Hke an except statsinsm oontsMng a haricler for each condit^ 
named, where each handler simply signals that exception with exacty Ins tame results. Thus, K the 
resignal clause names an exception with a specification in the routine heading of the form: 

namecn T n ) 

then effectively there is a handler of the form: 

when name (x, : T, x n : T„): [ abort \ signal name(x, >g 

which has an abort qualifier if and only X the resigns! statement did. As for an exploit handier of this 
form, every exception iwtenlle^ 

as declared m the exception specification, and the types of the resuts niust be ir«tua^ In the 
in the exception specification. 

If no abort qualifier is present, then all containing actions (If any) terminated by this statement are 
committed, if the abort qualifier is present, then ad tem^nsted actiw are aborted. Unfike the leave 
statement, resigns! wW abort concurrent sttfngs V executed wthin a ooenter statement (see Section 
10.6). The abort qualifier cm oniy be uesdtexiuaty 
coarm of a eosntsr statement, or the body of a handier or creator. 

11.4. Exit Statement 

An exit statement has the form: 

[abort] exit name [(expression,...)] 
An exit statement is similar to s signal statement except that where the signal statement signals an 
exception to the catting routine, the exit statement reft** the exception dreoUy m the current routine. 
Thus an exit causes s transfer of control wthin a routine but doss not terminate the routine. An 
exception raised by an exit statement must bs handled exp^ictly by a cortair^ sxcept sUHement with a 
handler of the form: 

when name ,...[( decl ,...)] : body 
As usual, the types of the expressions in the exit stetemert nsjst bs inciiJdsd in ths types of ths v 
declared in the handier. The handler must bs an explicit ons, i.e., exits to the impact handlers of reslgnsl 
statements are illegal. 

if no abort qualifier is present, then all containing actions (if any) terminated by tie exit statement are 
committed, if the abort qualifier is present, then all terminated actions are aborted. Unite the leave 
statement, exit wiH abort concurrent siblings when control flow leaves a oortaMng ooenter statement 
(see Section 10.6). The abort qualifier can only be used textual wilriin an enter stalement or an action 
or topactlon coarm of a eosntsr statement. 
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The welt statement and the signal statement mesh nicely to form a uniform mechanism. The signal 
statement can be viewed simply as terminating a routine activation; an exit is then performed at the point 
of invocation in the caller. (Because this exit is implicit, it is not subject to the restrictions on exits listed 
above.) 

11.5. Exceptions and Actions 

A new action is created by a handier caH, creator cad, enter statement, or action or topactton arm of a 
coenter statement. In addition, the recover code of a guardian runs as an action. When control flows 
out of an action, that action is committed unless action is taken to prevent as commuting. To abort an 
action, it is necessary to qualify control flow statements such as exft, etgnal, resignat, art leave with the 
keyword abort (see Section 10). 

However, there is an additional complication. Not only wU explicit termination of actions by exit, 
signal, and reslgnai statements commit actions, but also Imp** termination by flow of control out of an 
action body when an exception raised within that body is handled ootoide the action's body. Thus,ifan 
exception which is raised by a caH within an action is not to commit the action, then it is necessary to 
catch the exception wlthm the action. TNs is particularly important when dealing with topactions. A 
common desire is to catchall -unexpected" exceptions, but stM neve the topaction abort. In this case, the 
catch-all exception handler must be placed inside the topaction. However, an unavailable handler must 
still be placed outside the topaction, since the twoi>hase commtt may fall. 

An action or topaction coarm of a coenter statement will not abort its concurrent sfoHngs when it ends 
in either normal completion of its body or by a leave statement. However, il cjontroi flows otherwise out of 
the coenter statement from within one of the coarms, the entire coenter is terminated as described in 
Sectionl0.6. Thus, a coenter statement should must be used carafuRy to ensure the proper behavior in 
case of exceptions. There may be circumstances where a separate exception handler will have to be 
used for each coarm to ensure the proper behavior, even when the exception handling is identical for 
each coarm. 

11.6. Failure Exceptions 

Argus responds to unhandled exceptions differently than CLU. In CLU, an unhandled exception in 
some routine causes that routine to terminate with the failure exception. In Argus, however, an 
unhandled exception causes the guardian that is running the routine to crash. Our motivation for this 
change is that an unhandled exception is typically a symptom of a programming error mat cannot be 
handled by the calling routine. Furthermore, crashing the guarolan limits the damage that the 
programming error can cause. 

Procedures and Iterators in Argus no longer have an implicit failure exception associated with them. 
Instead, such a routine may list failure explicitly in its signals clause and failure may have any number 
(and type) of exception results. Failure should be used to indicate an unexpected (and possibly 
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catastrophic) failure of a lower-level abstraction, for txaiiipte, wha« 11^ Ji t lafaia in a type paramat^s 
routines (for instate stoiiarorawo^ Another example it when there is an unwanted side 
effect, such as a bounds exception m mm*mm mmmt t» * mMMon <* to mmy *»***. 
Various operations of the built-in types signal teflbre under such i 



For handlers and creators, Mun is used to indteare that a temore cat haa fased; thw 
fa*un(iM0Q) is impHdt in the type of every handera**creelor(»eeSec*>nl3.5). When a remote can 
terminates with the failure exception, this means that not only has tNs cal failed, but that the cail is 
unlikely to succeed If repeated. 
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12. Modules 

Besides guardian modules, Argus has procedure, iterator, cluster, and equate modules, 
module ::= { equate } guardian 
| { equate } procedure 
| { equate } Iterator 
| { equate } cluster 
| { equate } equates 
Guardians are discussed m Section 13, the rest are described below. 

12.1. Procedures 

A procedure performs an action on zero or more arguments, and when it terminates it returns zero or 
more results. A procedure implements a procedural abstractor, a mapping from a set of argument 
objects to a set of result objects, with possible modification of some of the argument objects. A procedure 
may terminate in one of a number of conditions; one of these is the normal condition, while others are 
exceptional conditions. Differing numbers and types of results may be returned in the different conditions. 

The form of a procedure is: 

idn - proc [ parms ] args [ returns ] [ signals ][ where ] 
routine Jbody 
end idn 



where 



args 

returns 

signals 

exception 

routinejbody 



:=([decl,...]) 
:= returns ( type_spec , ... ) 
::■ signals ( exception , ... ) 
:= name [ ( type_spec ,...)] 
:s { equate } 

{ ownjrar } 

{ statement } 



In this section we discuss non-parameterized procedures, in which the parms and where clauses are 
missing. Parameterized modules are discussed in Section 12.5. Own variables are discussed in Section 



12.7 



The heading of a procedure describes the way in which the procedure communicates with its caller. 
The args clause specifies the number, order, and types of argumerts re<xrired to call the procedure, while 
the returns clause specifies the number, order, and types of results returned when the procedure 
terrrtriatesnomiaMytbyexscutingaritum A missing refums 

clause indicates that no results are returned. 

The signals clause names the exceptional conditions in which the procedure can terminate, and 
specifies the number, order, and types of result objects returned in each condition. AH names of 
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exceptions in the signals clause must be distinct. The kin following the end of the procedure must be the 
same as the kin naming the procedure. 

A procedure is an object of some procedure type. For a non-parameterized procedure, this type is 
derived from the procedure heading by removing the procedure name, rewriting the formal argument 
declarations with one Mr? per dec/, deleting the Uns of all formal arguments, and finally, replacing pree by 
proctype. 

The call of a procedure causes the introduction of the formal variables, and the actual arguments are 
assigned to these variables. Then the procedure body is executed. Execution terminates when a return 
statement or a signal statement is executed, or when the textual end of the body is reached. If a 
procedure that should return results reaches the textual end of the body, the guardian crashes due to this 
error. At termination the result objects, if any, are passed back to the caller of me procedure. 

12.2. Iterators 

An Iterator computes a sequence of Items, one Kern at a time, where an torn is a group of zero or more 
objects. In the generation of such a sequence, the computation of each Mem of the sequence is usually 
controlled by information about what previous Items have been produced. Such information and the way 
it controls the production of Kerns is local to the iterator. The user of the aerator is not concerned wtth 
how the items are produced, but simply uses them (through a for statement) as they are produced. Thus 
the iterator abstracts from the details of how the pro 

consider an iterator to implement a control abstraction. Iterators am particularly useful as operations of 
data abstractions that are collections of objects (e.g., sets), since they may produce the objects in a 
collection without revealing how the collection is represented. 

An iterator has the form: 

Wn - Iter [ parms ] args [ yields ][ signals ][ where ] 
routinejbody 
endldn 
where 

yields ::= yields ( type.spec , ... ) 
In this section we discuss non-parameterized iterators, in which the parms and where clauses are 
missing. Parameterized modules are discussed in Section 12.5. Own variables are dtauesed m Section 
12.7. 

Trw form of an Iterator is sin^lar to trwfomi of a procedure. There are only two differences: 

1 . An iterator has a yields dame in its heading in place of the returns clause of a procedure . 
The yiekts clause specifies the number, order, and types of objects yielded each time the 
iterator produces the next Item in the sequence. N zero objects ass yielded, then the yields 
clause is omitted. The kin following the and of the Iterator must be the same as the Mb 
naming the iterator. 

2. Within the iterator body, the yield statement is used to present the caller with me next Kern 
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in the sequence. An iterator terminates in the same manner as a procedure, but it may not 
return any results. 

An iterator is an object of some iterator type. For a non-parameterized iterator, this type is derived from 
the iterator heading by removing the Iterator name, rewriting the formal argument declarations with one 
kin per ded, deleting the Una of all formal afgurnerits, ar«J ftiaJly, replace Iter by Itertype. 

An iterator can be called only by a tor statement or by a toreach clause in a coenter statement. 

12.3. Clusters 

A cluster is used to implement a new data type, distinct from any other bum-in or user-defined data 
type. A data type (or data abstraction) consists of a sat of objects arid a set of primlkve operations. The 
primitive operations provide the most basic ways of manipulating the objects; ultimately every 
computation that can be performed on the objects must be expressed In temis rt tfw primitive operations. 
Thus the primitive operations define the lowest level of observable object behavior 10 . 

The form of a cluster is: 

idn - cluster [ parms ] Is opidn ,...[ where ] 
ciusterjbody 
end idn 
where 

opidn ::= idn 
| transmit 

cluster_body : := { equate } rap - type_spec { equate } 
{ own_var } 
routine { routine } 

routine ::s procedure 
| iterator 

In this section we discuss non-parameterized clusters, in which the parms and where clauses are 
missing. Parameterized modules are discussed in Section 12J. Own variables are discussed in Section 
12.7. 

The primitive operations are named by the Hst of opUns following the reserved word Is. All of the 
opidnski this list must be distinct. The kin following the end of the duster must be the same as the ft*> 
naming the cluster. 

To define a new data type, it is necessary to choose a concrete representation for the objects of the 
type. The special equate: 
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rep « type_spec 
wHWn the cluster body identifies the type_spec as the concrete representation. Within the cluster, rap 
may be used as an abbreviation tor this type_spec. 

The io^ntifiernamir^trw cluster ie available for use in the cluster body. Use of this identifier within the 
cluster body permits the definition of recursive types. 

In addition to giving the representation of objects, the cluster must implement the primitive operations 
of the type. One exception to this, however, is the transmit operation. The transmit operation is not 
directly implemented by a cluster; instead, the duster must implement two operations: encode and 
decode (see Section 14 for details). The primitive operations may be either procedural or control 
abstractions; they are implemented by procedures and Iterators, respectively. Any additional routines 
implemented within the duster an hidden: they are private to the duster and may not be named directly 
by users of the abstract type. Ail the routines must be named by distinct identifiers; the scope of these 
identifiers is the entire cluster. 

Outside the duster, the type's objects may only be treated abstractly (i.e., manipulated by using the 
primitive operations). To implement the operations, however, It is usually necessary to manipulate the 
objects in terms of their concrete representation. It is also convenient sometimes to manipulate the 
objects abstractly. Therefore, inside the cluster it is possfcle to view the type's objects either abstractly or 
in terms of their representation. The syntax is defined to specify unambiguously, for each variable that 
refers to one of the type's objects, which view is being taken. Thus, inside a cluster named T, a 
declaration: 
v:T 

indicates that the object referred to by v is to be treated abstractly, wNte s declaration: 
w:rep 

indicates that the object referred to by wis to be treated concretely. Two primitives, up and down, are 
available for converting between these two points of view. The use of up permta a type rap object to be 
viewed abstractly, while down permits an aftstrad objsd to be viewed Generate*. For example, given 
the declarations above, the following two assignments ate legal: 

v > up(w) 

w > down(v) 

Only routines inside a cluster may use up and down. Note that up and down are used merely to inform 
the compiler that the object is going to be viewed abstractly or oonerateiy, respectively. 

A common place where the view of an object changes is at the interface to one of toe type's 
operations: the user, of course, views the object abstractly, whit inside the operation, the object is 
viewed concretely. To facilitate this usage, a special type spscttceJiefl, t¥t, is provided. Theuseofcvt 
is restricted to the orgs, returns, yields and 9^a^8c^»%^To^^M^k^^^^^,as^an^^^\^ 
at the top level only (e.g.. anayfcvt] is illegal). When used inside the args clause, it means that the view 
d the argument object changes from abstrad to concrete when it is assigned to the formal argument 
variable. When cvt is used in the returns, yields, or signals dause, it rneam the view <* the result object 
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changes from concrete to abstract as it is returned (or yielded) to the caller. Thus cvt means abstract 
outside, concrete inside: when constructing the type of a routine, cvt is equivalent to the abstract type 
butwhentypeKjbeckingtheb«*ofa Thetypeof 

each routine is derived from its heading in the usual manner, except that each occurrence of cvt is 
replaced by the abstract type. The cvt form does not introduce any new ability over what is provided by 
up and down, it is merely a shorthand for a common case. 

Inside the cluster, it is not necessary to use the compound form (<^spec$cp_riame) for naming 
locally defined routines. Furthermore, the compound form cannot be used tor calling hidden routines. 

12.4. Equate Modules 

An equate module provides a convenient way to define a a set of equates tor later use by other 
modules. 

The form of an equate module is: 
idn - equates [ parms [where ] ] 
equate { equate } 
end idn 

The usual scope rules apply. The Idn following the end of the equate module must be thesameasthe 
Idn naming the equate module. 

In this section we discuss non-parameterized equate modules. Parameterized modules are discussed 
in Section 12.5. 

An equate module defines a set of equates, that is. It defines a set of named constants The set of 
equates is also a constant, although K is not an object. Thus the name of an equate module can be used 
ki an equate, but an equate module cannot be assigned to a variable. The equates defined by an equate 
module E may be referenced using the same syntax as for tuning tlie opentfons of a cluster. For 
example, an object or type named n in equate moduto £ can be referred to as £^. If equate modules 
contain equates that give names to other equate modules, aanpound names can be used. Forexample- 
A{lntJ$B$C$name ^' 

where A, B, and Care equate modules is legal. 

As always, equates to type specifications do not define new types but merely abbreviations tor types. 
For example, In the following: 

myjypes -equate* 
ai - arrayfjnt] 
float -real 
end myjypes 

the types myjypes$ai and arrayfjnt] are equivalent. 
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12.5. Parameterized Modules 

Procedures, iterators, dusters, guardians (see Section 13), and equate modules may all be 
parameterized. Parameterization permits a set of related abstractions to be defined by a single module. 
In each module heading there is an optional parms clause arrt an c^tonali»f>^» clause (see Appendix I). 
The presence of the perms clause indicates that the module is parsmeterteed; the wfw» clause declares 
the types of any operation parameters that are expected to accompany the formal type parameters. 

The form of the parms clause is: 
[ parm , ... ] 
where 

parm ::= idn , ... : type_spec 
| idn , ... : type 
Each parm declares some number of formal parameters. Only the following types of parameters can be 
declared m a parme clause: Int, real, boot, char, strtng, null, and type. The declaration of operation 
parameters associated with type parameters is done in ttw where dause.M discussed below. The actual 
values for parameters are required to be constants that can be computed at compNe-time. This 
requirement ensures that aH types are known at oornpfle-time, and permits conptete eompHfrtime type- 
checking. 

In a parameterized module, the scops rules permit the parameters to be used throughout the module. 
Type parameters can be ueed freely as type specifications, and al other parameters (including the 
operations parameters specified in the where clauee) can be used freely as expressions. 

A parameterized module implements a set of related abstractions. A program must Instantiate a 
parameterized module before R can be used; that is, it must provide actual, constant values for the 
parameters (see Section 12.6). The result of an instantiation is a procedure, iterator, type, guardian, or 
equate module that may be used just Ike a non-parameterized module of the same kind. Each distinct 
list of actual parameters produces a distinct procedure, iterator, type, guardian, or equate module (see 
Section 12.6 for details). 

The meaning of a parameterized module is given by binding the actual parameters to the formal 
parameter names and deleting the parmsclauss and the where clause. That is, in an an instantiation of a 
parameterized module, each formal parameter name denotes the corresponding actual parameter. The 
resulting module is a regular (non-parameterized) module. In the case of a cluster some of the operations 
may have additional parameters; further bindings take place when these operations are instantiated. 

in the case of a type parameter, one can also declare what operation parameters must accompany the 
type by using a where clause. The when clause also specifies the type of each required operation 
parameter. The when clause constrains the parameterized module as wed: the only operations of the 
type parameter that can be used are those listed m the where clause. 
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The form of the where clause is: 

where "s where restriction , ... 
restriction ::= Wn has oper_decl , ... 

| idnmtype.set 

oper_decl ::= name , ... : type_spec 

I transmit 

type_set ::= { idn | idn hat operjtecl , ... { equate }} 

| idn 

I reference $ name 

There are two forms of restrictions, in both forms, the initial idn must be a type parameter. The has 
form lists the set of required operation parameters directly, by means of aperjdede. The type_spec in 
each<^j^nwstbeapiioctypa,lteity|»,or The In form requires that 

the actual type be a member of a typejBei, a set of types with the required openitone. The two identifiers 
in the typejaet must match, and the notation is read Kke set notation; tor example, 

{t { t has f: ... } 
means "the set of aH types t such that /has f...\ The scope of the Identifier is the type_set. 

The In form is useful because an abbreviation can be given tor a type_set via an equate. If R is helpful 
to introduce some abbreviations in defining the type jut, these are given in the optional equates within 
the typejset. The scope of these equates is the entire typejtet. 

A routine In a parameterized cluster may have a where clause In its heading, and can place further 
constraints on the cluster parameters. For example, any type is permisstote tor the array element type, 
but the array s/mflar operation requires that the elemere type ha*» a aimear operation. This means that 
afraylT] exists tor any type T, but that arrayf 7]$s*n*sr exists only when an actual operation parameter is 
provided for T«s*n«ar (see Section 12.6). Note that a routine need not include m its wnere clause any of 
the restrictions included in the cluster where clause. 

12.6. Instantiations 

To instantiate a parameterized module, constants or typs specifications are provided as actual 
parameters: 

actual_parm ::= constant 
I type_actual 

type_actual ::= type_spsc [ with { opbinding ,...}] 

opbinding ::= name , ... : primary 
If the parameter is a type, the module's where clause may require that some routines be passed as 
parameters. These routines can be passed ImpUcWy by orriNtirig the i^clause; the routine selected as a 
default wHI be the operation of the type that has the same name as that used in the where clause. 
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Routines may also be passed explicitly by using the wm clause, overriding the default. In this case, the 
actual routine parameter need not have the same name as is required in the where clause, and need not 
even be one of the type's primitive operations. 

The syntactic sugar that allows default routines to be selected implicty works as follows. If a generator 
requires an operation named op from a type parameter, and K the corresponding type_actmU, TS with { 
... }, has no explicit binding for op, then Argus adds an cpbtxfngof apto TS$op. (It wfll be an error if 
TS$op is not defined.) Thus one only has to provkte an expMettopotidirtg tftte 

For example, suppose a procedure generator named sort has the following heading: 

sort - procft: type](a: artaypD whan t has gt: proctypetf.t) returns<bool) 

and consider the three instantiations: 

sort[lntwWi{gt:lnt$gt}] 

sort{lnt] 

sort{lntwlth{lt:lnt$tt}] 

The first two instantiations are equivalent; in the first the routine W$gt is passed explicitly, while in the 

second it is passed implicitly as the default. In the third instantiation, however, tot$# is passed inplaceof 

the default. All three instantiations result in a routine of type: 

proctype (arrayftot]) 

and so each could be called by passing it an anayflnt] as an argument. However a call of the third 

instantiation will sort Its array argument in the opposite order from a can of either the first or second 

instantiation. 

Within an instantiation of a parameterized module, an operation of a type parameter named &op 
denotes the actual routine parameter bound to op in the Instantiation of that module. For example, 
suppose we make the caH: 

sortflnt with {gt: lnt$tt} ] (myjnts) 
where myjnts)* an array of integers. If , in the body of sort, there is a recursive caH: 

somtw»h{gt:t$gtn(a,i 1 J) 
then t denotes the type int, and t$gt denotes the routine mt$/f, so that the recursive sort happens in the 
correct order. 

A cbster generator may include routines with where clauses that place additional requirements on the 

cluster's type parameters. A common example is to require a copy operation only within the cluster's 

copy implementation. 

set - dussMft: type] la .... copy 

whan t has equal: proctype(t,t) returns(bool) 
rap - arrayft] 

copy - proc(s: cvt) returns(cvt) whan t has copy: proctype<t) returns^) 
retum(rep$copy(s)) 
and copy 

The intent of these subordinate where clauses is to allow more operations to bs defined If the actual type 
parameter has the additional required operations, but not to make the addttonaJ operations an absolute 
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requirement for obtaining an instance of the type generator. For example, with the above definition of set 
se(any] would be defined, but s*<any]$copy would not be defined because any does not have a copy 
operation. We shad caN the routine parameters required by subordinate where clauses optional 
parameters. 

Like regular required parameters, optional parameters can be provided when the duster as a whole is 
instantiated and can be provided explicitly or by default. For any optional parameter op that is not 
provided explicitly by the type__actuaj, TSwtth {...}, we add an opbtnOng of op to 7S$oplf TStop exists; 
otherwise the opbinding is not added. The resulting duster contains Just those operations for which 
opbindkigs exist for all the required routine parameters. For example, as mentioned above, setfany] 
would not have a copy operation because anyfccpy does nd exid wid therefore the needed cpfcsioftv is 
not present. On the other hand, septt] does have a copy operation because Intfcopy does exist. 
Finally, set>ny with {copy, too)], where too is a procedure that takes an any as an argument and returns 
an any as a result, would have a copy operation. 

For an instantiation to bs legal It must type check. Type checking is done after the syntactic sugars are 
applied. The types d constant parameters mud be included in the declared type, type actuate mud be 
types, and the types d the actual routine parameters mud be Included in the proctypes, ttertypes, or 
credortypes dedared in the appropriate where clauses. Of course, the number d parameters declared 
mud match the number d actuals passed and with each type actual parameter there mud be an 
opbinding for each required routine parameter. If me generator is a duster, men opbinding* mud be 
provided for dl operations required in the duster's when ctauss; opbincHngs can (but need nd) be 
provided for optional parameters. Extra actual routine parameters are Nlegd. 

Because the meaning d an instantiation may depend on the actual routine parameters, type equality 
makes instances with different actual routine parameters distinct types. For example, consider the set 
type generator again; the instance 

sst[ arrayflnt] with {equal: array(lnt]$equa!} ] 
is nd equal to 

sett arrayflnt] with {equal: array[lnt]$sim«ar} ] 
Intuitively these instances should be unequal because the two equal procedures ddine different 
equivalence classes and therefore the abstract behaviors d the two Instances are differed. However, 
optional parameters do not effect type equality. For example, 

set(array{lnt] with {copy: lnt$copy} ] 
and 

setfarraypnt] with {copy: my_copy} ] 
are equal types. This is intuitively justified because in each case sd objects behave the same way even 
though different sets are produced when sets are copied in the two cases. 

Thus we have the following type equality rule, which ddines when two type_specs denote equal types 
(after syntactic sugars are applied). A similar notion is also needed tor routine equality. A formal type 
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identifier is equal only to itself for type checking purposes. Otherwise, two type names denote equal 
types K they denote the same Description Unit (DU). 11 Similarly, Argus compares the names of routine 
formate or the DUs of routines, or checks that they are the same operation In equal types. To decide the 
equality of two type generator instantiations: 

T^ with {op,: act,, ... op m : acy t n with {...} J 

and 

TIV with {op,: act,', ... op m : act^ 1 } t n ' wtth {...} ] 

Argus first checks whether: 

1 . rand T denote the same DU, and whether 

2. they have the same number of typejactuaJa, and f, is equal to «,'. etc. 

Second, any optional parameter opbindings in either instantiation are deleted. After mis step, Argus 
checks that for each corresponding type_actual there is the same number of opbbdlnge and that each 
corresponding op6/nc«nfl is the same. (That is. the corresponding actual routines are equal.) The order 
of the actual routine parameters does not matter, since Argus matches opbindings by operation names. 
(The definition of routine equality for instantiations of routine generators is similar.) This definition, for 
example, tells us that 

set{ arrayfjnt] wtth {equal: array[lnt]$equal} ] 
is different from 

set(arTayItot] wtth fecial: afraynrtlSsimilarl] , 
(assuming set requires an equa/operation from its type parameter). It also tells us that: 

sett Int wtth {equal: too, copy: bar} ] 
and 

set{ Int wtth {equal: too, copy: xerox} ] 
are equal (assuming copy is required only by the se<im]$copy operation). 

This type equality rule allows programmers to control what requirements affect type equality by 
choosing whether to put them on a cluster or on each operation. A requirement on the cluster should be 
used whenever the actuals make some difference in the abstraction. For example, in the set cluster, the 
type parameter's equal operation should be required by the duster as a whole, since using different 
equality tests for a set's objects causes the set's behavior to change. 

One can require that a type parameter, say t, be transmisstole by stating the requirement: 
t has transmit 

This requirement is regarded as a formal parameter declaration for a special "transmit actual", but Argus 
does not provide syntax for passing It explicitly. The "transmit actual" is passed implicitly just when the 
actual type parameter Is transmissible and the generator requires R. 



1 1 This is name equality unrest the type environment has synonyms far types. 



12.7 Own Variables K 

12.7. Own Variables 

Occasionally it is desirable to have a module that retains information internally between calls. Without 
such an ability, the Information would either have to be reconstructed at every call, which can be 
expensive (and may even be impossftxe if the Information depends on previous calls), or the Wormation 
would have to be passed m through arguments, which is undesirable because the information is then 
subject to uncontrolled modification mother modules (but see also the binding mechanism described In 
Section 9.8). 

Procedures, iterators, handlers, creators, and clusters may al retain information through the use of 
own variables. An own variable is similar to a normal variable, except that it exists tor the We of the 
program or guardian, rather than being bound to trie ifto of ariy pertkuiar louttoe acuVation. Syntactically, 
own variable declarations must appear Immediately after the equates in a routine or cluster body; they 
cannot appear in bodies nestsd wfthto statements. Declarations of own variables have the form: 
own_var : :s own ded 

| own idn : typs_spsc > expression 
| own decl , ... > caN [ <8> primary ] 
Note that initialization is optional. 

The own variables of a module are created when a guardian begins execution or recovers from a 
crash, and they always start out uninitialized. The own variables of a routine (including cluster 
operations) are initialized m textual order as part of the first cai of an eperatkm of that rcos^ 
such caN after a crash), before any statements in the body of the routine are executed. Cluater own 
variables are initialized in textual order aspertofthefirstcaJofthefrst duster operation to be cased 
(even if the operation does not use the own variables). Ouster own variables are initialized before any 
operation own variables are initialized. Argus insures that only one process can execute a cluster's or a 
routine's own variable initializations. 

Aside from the placement of their declarations, the time of their initialization, and their lifetime, own 
variables act Just Hke normal variables and can be used to al the same places. Aa with normal variables, 
an attempt to use an uninitialized own variable (If not MKiMXcon^tkTHjwHia^itegjwtonxo 
crash. 

Declarations of own variables in different modules always refer to dWnct own variables, and distinct 
guardians never share own variables. Furthermore, own variable declanMtons w*Nn a perameterized 
module produce distinct own variables for each distinct tattansaten of the module. For a given 
instantiation of a parameterized cluster, all fcstaritiatlone of trw type's ope 

cluster own variables, but distinct instantiations of parameterized operations have dfetinct routine own 
variables. 

Declarations of own variables cannot be enclosed by an except statement, so care must be exercised 
when writing initialization expressions. If an exception is raised by an initialization expression, It wM be 



86 

Modules 

treated as an exception raised, but not handled, in the body of the routine whose call caused the 
initialization to be attempted. Thus, the guardian will crash due to this error. 
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stable buffer: Momtejmaypm] :- atomic Mrayflntffnew ( ) 
cache: arrayflnt] :- arrayflntffnew ( ) 

then the atomic_array object denoted by buffer wouU survive a guardian crash, but the array object 
denoted by cache would not. See Section 13.3 for more details of crash recovery. VoJatfle variables can 
be assigned wherever an assignment statement is legal. However, stable variables may only be 
assigned by an initialization when declared or in the body of a creator. The kntiatizations of both stable 
and volatile variables are executed within an action, as described below. However, the stable variables 
are not reinitialized upon crash recovery, whereas volatile variables are retoftiafized upon crash recovery. 

Stable variables should denote resilient objects (see Section 15.2), because only resilient data objects 
(reachable from the stable variables) are written to stable storage wtien a topsclkm oonmKs. (This can 
be ensured by having stable variables only denote objects of an atomic type or objects protected by 
mutex.) Non-resilient objects stored In stable variables are only written to stable storage once, when the 
guardian is created. Furthermore, the stable variables should usually denote atomic objects, because the 
stable variables are potentially shared by all the actions m a guardian. 

13.2. Creators 

A guardian definition must provide one or mors creators. The names of these creators must be listed 
in the guardian header (internal creators are not allowed); each such nam* must correspond to a single 
creator definition appearing In the body of the guardian definition. 

A creator definition has the same form as a procedure definition, except that creators cannot be 
parameterized, and the reserved word creator is used In place of proc: 

idn - creator ([ args ]) [ returns 1 [ signals 1 
routine body 
end idn 

The initial idn names the creator and must agree with the final Idn. The types of ail arguments and all 
results (normal and exceptional) must be transmissible. 

A creator is an object of some creator type. This type is derived from the creator heading by removing 
the creator name, rewriting the formal argument declarations wim one JbV? per o^ deleting the idns of aH 
formal arguments, deleting any failure or unavailable signals, and finally, replacing creator by 
creatortype. The signals fe;/ure(string) and unavailable(*r\nQ) are implicit in every creator type (since 
they can arise from any creator call). However, If these signals are raised explicitly by a creator, they 
must be listed in the signals clause with string result types. 

The semantics of a creator can are explained in Section 8.4. Typically, the body of a creator will 
initialize some stable and volatile variables. It can also return the name of the guardian being created 
using the expression self. Since the creator (and the state initialization) runs as an action, the creator 
terminates by committing or aborting. H it aborts, the guardian is destroyed. If K commits, the guardian 
begins to accept handler calls, and runs the background code, if any (see betow). If an ancestor of the 
creator aborts, the guardian is destroyed. If the creator and all its ancestors commit, the guardian 
becomes permanent, and will survive subsequent crashes. 
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13.3. Crash Recovery 

Once a guardian becomes permanent, it wW be recreated automatically after a crash with its stable 
variables initiaJized to the same state they were in at the last topactton commit before the crash. The 
volatile variables are then Initlaiized (in oeciaration wder) 1^ a topactton. To aid in mis reinitialization, the 
guardian definition can provide a recover section: 

recover body end 
to be run, as part of this topactton, after the initializations attaclied to tiw volatile variable declarations are 
performed. The recover section commits when control reaches the end of the body, or when a return 
statement is executed. The recover section may abort by executing an ab<Ht return statement or as a 
result of an unhandled exception. The guardian crashes H the recover section aborts. 

13.4. Background Tasks 

Tasks that must be performed periodically, Independent of handler calls, can be defined by a 
background section: 

background body end 
The system creates a process to run this body as soon as creation or recovery commits successfully. 
The body of the background section does not run as an action; typfeasy it wiN perform a sequence of 
topacttons. 

If the background process finishes executing fts body (either by reaching the end of the block or by 
returning), the process terminates, but the guardian continues to execute incoming handier cans. 

13.5. Handlers and Other Routines 

Typically, the principal purpose of a guardian is to execute incoming handler calls. A guardian accepts 
handler cads as soon as creation or recovery commits. 

The guardian header lists the names of the externally available handlers. Each handler listed must be 
defined by a handler definition. Additional handler definitions may also be given, but these handlers can 
be named only within the guardian to which they belong. 

A handler definition has the same form as a procedure definition, except that handlers cannot be 
parameterized, and the reserved word handler is used in place of proe: 
idn - handler ([args])[ returns] [signals] 
routinejbody 
end idn 

The initial Idn names the handler and must agree with the final idn. The types of all arguments and ail 
results (normal and exceptional) must be transmissible. 

A handler is an object of some handler type. This type is derived from the handler heading by 
removing the handler name, rewriting the formal argument declarations with one idn per dec/, deleting the 



so 








.>7P-?§ov-'<« •^■^• : '}~A'^:^^i , ^f'^^0:''i' ■ 




13.7 An Example 

511 

consumption. The spooler provides an operation for adding (object, consumer) pairs, and for destroying 
the guardian. 

Figure 13-1: Spooler Guardian 



spooler . guardian [t: type] la create handles enq, finish 
where t has transmit 

utype - handlertype (t) 

entry - atruet[object: t, consumer: utype] 

queue - sernJqueuefentry] 

stable state: queue :- queue$create() 

background 
while true do 
enter topact Ion 

e: entry :« queue$deq(8tate) 
e.consurnsr(s.objsct) 

except when unavasabw (*): abort leave and 
and except whan failure, unavailable (*): and 
and 
and 

create - creator () returns (spooferft]) 
retum(eetf) 
and create 

enq - handler (item: t, user: utype) 

queue$enq(state, st«ry${objsct: Kern, consumer: user}) 
end enq " 

finish- handler () 
terminate 
and finish 

end spooler 



The spooler guardian is parameterized by the type c^ object to be stored. The enq hanoter takes an 
object of this type, and a handler for sending the ctk« to the consiinw. and adds this Wcrn^ 
stable state of the spooler. This state is an object of the aemftpjeue abstract datatype". Eachentryin 
tne semiqueue is a structore ccfluunlng a stored ct^ T^ 

background code of the guardian runs an WW* kx>p that star* a topacti^ 
queue, and sends the object using the associated handler. 

Note that an unavailable exception arising from mis hanoter c^ Is caugN irx^ the tcpactton so that 
an explicit abort can be performed. If the exception were caught outside the topactton, It would cause the 
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topaction to commit, and the entry would be removed without being consumed. Note also that failure is 
caught outside the topaction, since if an encode were to fan. or If the guardian did not exist, the 
background process might aimlessly loop forever, because it would not be able to remove that entry. 

A more extended example of a distributed system appears in the paper Liskov, B. and Scheifler, R., 
-Guardians and Actions: Linguistic Support for Robust, Distributed Programs," ACM Transactions on 
Programming Languages and Systems, volume 5, number 3, (July 1983), pages 381 -404. 
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14.3. Transmit for Abstract Types 

The type implemented by a duster is transmtesfcte if the reserved wad transmit appears in the la-list 
at the head of the cluster. UnUke the other operations provided by a type, the ttansmK operation cannot 
be called directly by users, and m fact is not Implemented directly in the cluster. Instead, transmit is 
implemented indirectly In the following way. Each transmissbie type is given a canonical representation, 
called its external representation type. The external representation type of an abstract type Tie any 
convenient transmissbie type XT. This typs can be another abstract type If desired; there is no 
requirement that XT be a butt-in type. Intuitively, the meaning of the external representation is that 
values of type XT will be used in messages to represent values of type T. The choice of external 
representation type is made tor the abstract type as a whole arxl must be used In ev^ impternentatton of 
that type. (There are currently no provisions tor changing the external representation of a type once it 
has been established in the Horary.) 

Each implementation of the abstract type T must provide two operations to map between values of the 
abstract type and values of the external representation type. There is an operation 

encode - proc (a: T) returns (XT) [ signals (failure(string)) ] 
to map from Tvalues to XT values (for sending messages) and an operation 

decode - proc (x: XT) returns (T) [ slgnaia (faiiure(strlng)) J 

to map from XT values to Tvalues (for receiving messages). The transmit operation for TIs defined by 
the following identity: 

T$transmtt (x) - T$decode (XT$transmH (T$encode(x))) 
Intuitively, the correctness requirement tor encode and decode is that they preserve the abstract T values: 
encode maps a value of type Tinto the XT value that represents ft, while decode performs the reverse 
mapping 14 . 

Encode and decode are called implicitly by the Argus system during handler and creator calls. If 
encode and decode do not appear in the cluster's to-Hst, then they wi be acoessft* to the Argus system, 
but may not be named directly by users of the type. A taMure exception raised by one of these operations 
will be caught by the Argus system and resignaJled to the caller (sse Section 8.3). 

An abstract type's encode and decode operations should not cause any side effects. This is because 
the number of calls to encode or decode is unpredictaWe. since arguments or results m^ 
and decoded several times as the system tries to establish cornmunicatton. in addftton, verifying the 
correctness of transmission is easier if encode and decode are simply transformations to and from the 
external representation. 

When defining a parameterized module (see Section 12.5), it may be necessary to require a type 
parameter to be transmissible. A special type restriction: 



14 Het«hy l M. and Liskov, B., "A Value Transmission Method for Afasftact Data Tyoee - ACM Tran—etanm on rm,» ■„„■■>, ■ 
Langvgm and Sesame, volume 4, number 4, (Oct 1962), pages 627^5^ ' TnnMet0f >* •» Pngmmmmg 
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has transmit 

is provided for this purpose. To permit instantiation only with transmissible type parameters, this 
restriction should appear in the where clause of the cluster. Alternatively, by placing identical where 
clauses in the headings of encode and decode procedures, one can ensure that an instantiation of the 
cluster is transmissfele only If the type parameters are transmisstote (see Section 12.5). 

As an example, Figure 14-1 shows part of a cluster defining a key-torn tebiexh* stores pairs of values, 
where one value (the ftey)isused to retrieve the other (the Asm). Ths key-Hem tabic type has operations 
for creating empty tables, inserting pairs, retrieving the Item paired wlm a given 1^, deleting paJre, and 
iterating through aH key-Kern pairs. The table is represented by a sorted binary tree, and its external 
representation is an array of key-ftem pairs. The table type Is transmissible only If both type parameters 
are transmissible. 

Figure 14-1: Partial implementation of table. 



'22? ^ ? em: lyp#l *• croate - inamt ' *****>> •"P**. <*»••». transmit, 
where ksy has H: practyps (key, key) returns (boot), 

equal: proctype (key, key) returne (boot) 

pair -recordfk: key, i:Kem] 
nod - recordfk: key. I: Hem. left, right: tabtefkey, Memn 
rep- variant{empty: null, some: nod] 
xrep-arreyftM*l % the external representation type 

t Z!?J[SrSi!!?^ ntaton * a "** """V tree. All pairs m me table 

£ 5 ?!i5 (riflW) * a nod * ""^ ^ *" *" (OnMtorman) the key in 
% tnat node. 

% ... other operations omitted 

encode - proc (t: tablefkey, Kern]) returns (xrep) 

where ksy has transmit, item has transmit 
xr: xrep :- xrep$nsw() % create an empty array 
% use aHpairs to extract ths pads from the tree 
torp:paJrlnallpairs(t)clo 

% Add the pair to ths high end of the array. 

xrep$addh(xr, p) 

end 
return(xr) 
and encode 

decode - proc (xtW: xrep) returns (tatXefkey, Hem]) 

whsre key has transmit, Hem has transmit 
t: taWefkey, asm} :- creato() % create empty table 
tor p: pair In xrep$etements(xr) do 

%xrep$elements yields all elements of array xr 

insertft, p.key, p.item) % enter pair in table 

and 
rstum(t) 
and decode 
and table 
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14.4. Sharing 

When an object of structured built-in type is encoded and decoded, snaring among the object's 
components is preserved. For example, let a be an arrey{7] object such that a(i] and aQ] refer to a single 
object of type T. tf a? is an array! 7] object created by transmitting a, then a2/// and a2B] also name a 
single object of type T. 

All snaring is preserved among all components of multiple objects of built-in type when those objects 
are encoded together. Thus, shalng is preserved for ob|sctotnataraai*u^ 
or are results of the same remote cal, unless the arguments are encoded at different times (see the 
discussion of the bind expression in Section 9.8). For example, tot a andb be array! 7] objects such that 
m and prefer to a single object of type T. If a2 and 62 are arrays created by sending a and 6 as 
arguments in a single handler call, then a2fl] and b2ffl also refer to a single object. 

Whether an abstract type's transmit operation preserves Sharif is part rt tr^ type's specif icatton, but 
sharing should usually be preserved for abstract types. In the key-Kern table implementation of Figure 
14-1 .there are two types of sharing that should be preserved: sharing of keys and Kerns among multiple 
tables sent in a single message, and sharing of Kerns bound to the same key in a single table. The 
key-Kem table example shows how to implement an abstract type whose transmission preserves sharing 
by choosing an external representation type whose transmit operation preserves sharing. 

Care must be taken when the references among objects to be tranemKted are cyclic, as m a circular 
list. Decoding such objects can result in a fe^ exceptkm unless enco* aito oecrte ^ 
in one of two ways: 

their argument object without modifying K or accessing Ks components, or 
2. the external representation object must be free of cycles. 
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15. Atomic Types 

In Argus, atomicity is enforced by the objects snared among actions, rather than by the individual 
actions themselves. Types whose objects ensure atomicity of the actions sharing them are catted atom/c 
types; objects of atomic types are called atomic objects, in this chapter we define what it means for a 
type to be atomic and describe the mechanisms provided by Argus to support the implementation of 
atomic types. 

Atomicity consists of two properties: serializability and recoverability. An atomic type's objects must 
synchronize actions to ensure mat the actions are aeriafeabte. An atomic type's objects must also 
recover from actions that abort to ensure that actions appear to execute either completely or not at an. 

In addition, an atomic type must be resilient the type must be implemented so that its objects can be 
saved on stable storage. This ensures that the effects of an action that commits to the top (that is, an 
action that commits, as do aft of its ancestors) wW survive crashes. 

This chapter provides definitions of the mechanisms used tor user-defined types in Argus. For 
example implementations, see Weihl, w. and Uskov, B., -trnpiementatton of Resident, Atomic Data 
Types," ACM Transactor* on Programming Languages and Systems, volume 7, number 2 (April 1985), 
pages 244-269. 

The remainder of this chapter is organized as toNows. in Section 15.1 and Section 15.2, we present 
the details of the mechanisms. Section 15.1 focuses on synchronization and recovery of actions, while 
Section 15.2 deals primarily with resilience. In Section 154, we dtocuss some guidelines to keep in mind 
when using the mechanisms described in Section 15.1 and Section 15.2. In Sections 15.4 and 15.5, we 
define more precisely what it means for a type to be atomic. Finally, in 15.6, we discuss some details that 
are important tor user-defined atomic types that are implemented using multiple mutexes. 

15.1. Action Synchronization and Recovery 

'n this section we describe the ra«**^ 
ofactlons. These mechanisms are designed specifically to support impiementatiom of atomic types that 
allow highly concurrent access to objects. 

Like a non-atomic type, an atomic type is Implemented by a duster tliat defines a represerto 
objects of the type, and an impiementatton for each operation ot tiie t»» to tenm of tiiat representation. 
However, the implementation of an atomic type must solve »c^ problems triat cto rxM occur for ofdinery 
types, namely: synchronizing concurrent actions, making viei* to ©tiw acttons the effecto ot eomntt^ 
actions, hiding the effects of aborted actions, and providing resilience against crashes. 

An implementation of a user-defined atomic type must bsabto to find out about the corn^ 
of actions. In Argus, implementations use objects of butt-in atomic types tor this purpose The 
representation of a user-defined atomic type Is typically a cont**lo« tf 
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changed - proc (m: mutexp]) 
is provided for notifying Hie system that an existing mutex object should be written to stable storage 
Calling this operation wW cause the object to be written to stable storage (assuinlng It is accessWe) by 
the time the action that executed the changed operation commas to the top. Sometime after the action 
cans changed, and before its top-level ancestor «MT«iteJhe system wM copy the nutex o 
storage. Changed wu^. be called from a process running an action. 

Mutex objects also define how rriuch intomttlon rnust be written to stai^ Copying a mutex 

object involves copying the contained object. By choosing the proper granularity of mutex objects the 
user can control how much data must be written to stable storage at a time. For example, a laige data 
base can be broken into partitions that are written to stable storage irxtependen^ by dM<*ng it among 
several mutex objects. Such a division can be used to Dms the amount of data written to stable storage 
by calling changed only for those partitions actually modified by a committing action. 

In copying a mutex object, the system will copy all objects reachabto from it, excluding other mutex or 
built-in atomic objects. A contained mutex or built-in atomic object wttt be copied only if necessary that is 
only if It is: 

"Sp2Ston° b,eCl for WWCh (a dMC8ndant *> the completing action called the changed 

• a built-in atomic object that was modified by the action, or 

• a newly accessible object for which no stable copy exists. 

Furthermore, the component is copied independently of the containing mutex object; they may be copied 
in either oraer (or simultaneously), subject to the constraint mat the system cannot copy a mutex object 
without first gaining possession of M. 

Finally, mutex objects can be used to ensure that infomiaiion is In a consisted state when it is written 
to stable storage. The system wfH gam possession of a mutex object before writing it to stable storage 
By making afl modifications to mutex objecte insloe lata swemei*. the ijs^ 
system from copying a mutex object when it is in an inconsistent state. 

Some details of the effect of changed are important for atorrfc types that a/e impiemented as multiple 
mutexes. These details are presented In Section 15.6. 

15.3. Guidelines 

This section discusses soma guidelines to be followed when impJemei*ng atomic types. There are 
additional guidelines to follow when multiple mutexes are used to implement an atomic type; those 
guidelines are discussed in Section 15.6. 

An important concept for describing the resilience of user-defined atoirite Anobject 

is synchronous K it Is not posstte to obaetve that any portion of the object Is <»pled to 
different time from any other portion. For example, an object of type amyfmuteaflnfa would not be 
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synchronous, because elements of the array can be oopted at d«f«rent times. A type is synchronous if atl 
of its objects are synchronous. Whether a type is synchronous or not is an important property of its 
behavior and should be stated in its specification. The built-in atomic types are synchronous; user- 
defined types must also be synchronous if they are to be atomic. 

To ensure the resilience and serlaHzabWty of a user-defined atomic type independently of how it is 
used, the form of the rap for an atomic type should be one of the foamring posafeMties. 

1. The rep is itself atomic. Note that mutex is not an atomic type. 

2. The rep is mutoxM where t is a synchronous type. For example, t could be atomic, or it 
could be the representation of an atomic type, if the operaliora on the thto fictttotis atomic 
type are coded in-Hne so that the entire type behaves atomteaJty. 

3. The rep is an atomic collection of mutex types containing synchronous types. 

4. The rep is a mutable collection of synchronous types, and objects of the representation 
type are never modified after they are WtJateed. That is, mutation may be used to create 
the initial state of such an object, but once this has been done the object must never be 
modified. 

When using mutex objects, there are a few rules to remember. First, changed must be called after the 
last modification (on behalf of some action) to the contained object. This is true because the Argus 
system is free to copy the mutex to stable storage as soon as changed has been called. 

In addition, changed should be called even if the object is not accesstote from the stable variables of a 
guardian. In part this rule is just an example of separation of concerns: the impiemeritation of the atomic 
type should be done independently of aiiy assuns^iora about how the olaeel w« be used Theretorethe 
type should be implemented as If its objects were accesstote from the staJ* varfaotes of some guardian. 
However, in addition, If this rule Is not followed, It is possible that stable storage wH not be updated 
properly. This situation can occur if an object was accesstole, then becomes kwccesstote, and later 
becomes accessible again. The system guarantees that no problems arise if changed* always called 
after the last modification to the object. 

Mutex objects should not share data with one another, unless the shared data is atomic or mutex. 
One reason for this rule is that in copying mutex objects to stable storage Argus does not preserve this 
kind of sharing. 

A final point about mutex objects is that it is unwise to do any activity that is likely to take a long time 
inside a seize statement. Focexampte.ahancaercaHshouWnotbeoto^ 

possible. Also, it is unwise to wait tor a lock inside a seize unless the progfwnmer can be certain that the 
lock is available or will be soon. Otherwise, a deadlock may occur. An example of where waiting for a 
lock m a nested setae statement is safe is where all processes seize the two mutex objects in the same 
order. 
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15.4. A Prescription for Atomicity 

In this section, we discuss how to decide how much concurrency is possfcie in impiementinB an atomic 
type. In writing specifications for atomic types, we have found It he^u) to p^ oown the behavtor of the 
operations, initially assuming no concurrency and no failures, and to deal wan concurrency and failures 
later. In other words, we imagine that the objects will exist in an environment in which an actions are 
executed sequentially, and in which actions never abort. 

Although a sequential specification of this sort does not say anything explicit about permissible 
concurrency, it does impose limits on how much concurrency can be provided. Incrementations can 
differ in how much concurrency is provided, but no Impiementation can exceed these Hmfts. Theretore.it 
te important to understand what the limits are. 

This section and the following section together provide a precise definition of permissbie concurrency 
for an atomic type. This definition is based on two facts about Argus and the way it supports 
implementations of atomic type. First, in implementing an atomic type, it is only necessary to be 
concerned about active actions. Once an action has committed to tie top. it is not possfele for it to be 
aborted later, and its changes to atomic objects become visfeto to other actions. So, for example, an 
implementation of an atomic type needs to prevent one action from observing the modMcaaofis of other 
actions that are still active, but It does not have to prevent an action from observing implications by 
actions that have already committed. Second, the only method svaHsbis to an stomk: type tor controlling 
the activities of actions is to delay actions while they are execute operations of the type. An atomic type 
cannot prevent an action from calling an operation, although R can prevent that call from proceeding. 
Also, an atomic type cannot prevent an action that previously finished a caM of an operation from 
completing either by committing or by aborting. 

Given the sequential specification of the operations of a type, these facto lead to two oonstraints on the 
concurrency permitted among actions using the type. Whse an Implementation can allow no more 
concurrency than perrmttod by these constraints, some I mp to menta ti orw . fee that tor the buNNn type 
generator atomlc_arTay (see Section 11.10), may alow toss concurrency than permitted by their 
sequential specifications and our concurrency constraints. 

The first constraint is that 

• an action can observe the effects of other actions only If those actions committed relative to 
the first action. 

This constraint implies that the results returned by operations executed by one action can reflect changes 
made by operations executed by other actions only if those actions committed relative to the first action. 
For example, In an atomic array a, If one action performs a storefe 8, 7), a second (unrelated) action can 
receive the answer "7" from a call of ftttnfa. 3) only I the first action oofnmtted to the top. If the first 
action is still active, the second action must be delayed until the first action completes. This first 
constrairt supports recowrabiBty s 

other actions. It also supports seriaUzaWHty, since it prevents concurrent actions from observing one 
another's changes. 
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However, more is needed tor sertalizabUtty. Thus, we have our second constraint: 

• operations executed by one action cannot Invalidate the results of operations executed by a 
concurrent action. 

For example, suppose an action A executes the size operation on an atomic array object, receiving n as 
theresult. Now suppose another action B is permitted to execute addh. The addh operation win increase 
the size of the array to n + 1, invalidating the results of the size operation executed by A Since A 
observed the state of the array before B executed addh, A must precede Bin any sequential execution of 
the actions (since sequential executions must be consistent win the sequential specifications of the 
objects). Now suppose that fl commits. By assumption. A cannot be prevented from seeing the effects of 
ft If * observes any effect of 8, MwW have to toftowS in any sequent execution. Since A cannot both 
precede and follow B\n a sequential execution, serializabity would be violated. Thus, once A executes 
size, an action that calls addh must be delayed until A completes. 

15.5. Commuting Operations 

To state our requirements more precisely, consider a simple situation involving two concurrent actions 
each executing a single operation on a shared atomic object X. (The actions may be executing 
operations on other shared objects also, but in Argus each c*^>ct rnust irtoMo^alV ensure the atoniicity of 
the actions using It, so we focus on the operations involving a single object.) A fairly simple condition that 
guarantees senaiizabKlty is the following. Suppose X is an object of type T. X has a current state 
determined by the operations performed by previously committed actions. Suppose O, and 2 are two 
executions of operations on Xh Its current state. (O r and O, might be executions of the same operation 
or different operations.) If O, has been executed by an action A and A has not yet committed or aborted, 
2 can be performed by a concurrent action Son* If O, and 2 commute: given the current state of X, 
the effect (as described by the sequential specification of 7) of performing 1 on X followed by 2 is the 
same as performing 2 on X followed by O v It is important to realize that when we say "effect" we 
include both the results returned and any modifications to the state of X 

The intuitive explanation of why the above condition works is as foflows. Suppose 1 and 2 are 
perforated by concurred actions A and at X If O r andO* commute, then the order in which A andS 
are serialized globally does not matter at X. If A Is serialized before ft then the k>cal effect at X is as if 0, 
were performed before O z whHe V B is serialized before A. the local effect is as If 2 were performed 
before O v But these two effects are the same since 0, and 2 commute. 

The common method of dividing operations into readers and writers and using reeoVwrtte locking works 
because it allows operations to be executed by concurrent actions only when the operations commute. 
More concurrency is posstote with our cornmutatMty condition than with readers/writers because the 
meaning of the individual operations and the aiguniento of me calls can be cwisidenxi. For example, 
cans of the atomic array operation addh always conimute wim caHs of aocl, vet both these operatiom 
writers. As another example, ston(X, i, e r ) and store<xy, ej commute If i*j. 

We require only that 1 and 2 commute when they are executed starting m the current state. 
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Consider a bank account object, with operations to deposit a sum of money, to withdraw a sum of money 
(with the possible result that tt signals insufficient funds N me current balance is less than the sum 
requested), and to examine the current balance. Two withdraw operations, say for amounts m and n, do 
not commute when the current balance is the maximum of m and m either operation when executed hi 
this state wW succeed in withdrawing the requested sum, but the other operation must signal insufficient 
funds H executed in the resulting state. They do commute whenever the current balance is at least the 
sum of m and n. Thus if one action has executed a withdraw operation, our concBtton allows a second 
action to execute another withdraw operation while the first action is stffl active as long as mere are 
sufficient funds to satisfy both withdrawal requests. 

Our condition must be extended to cover two additional cases. First, there may be more than two 
concurrent actions at a time. Suppose A p ... 9 A n are concurrent actions, each performing a single 
operation execution O;,...^ respectively, on X (As before, me concurrent actons may be sharing 
other objects as wefl.) Since A p ...,A n are permitted to be concurrent at K there is no local control over 
the order In which they may appear to occur. Therefore, afl possbie orders must have me same effect at 
X This is true provided mat all permutations of O p ...,O n have me same effect when executed in the 
current state, where effect includes both results obtained and modifications to X. 

The second extension acknowledges mat actions can perform sequences of operation executions. 
Consider concurrent actions A p ...,A n each performing a sequence Sp.^S^ respectively, of operation 
executions. This Is penriseble if all sequences S iP ^ t S^ obtained by concatenating me sequences 
Sp... t S,p in some order, produce the same effect. For example, suppose action A executed addh 
followed by remft on an array. This sequence of operations has no net effect on the array. It is then 
permissible to allow a concurrent action B to execute size on the same array, provided the answer 
returned is the size of me array before A executed addh or after it executed rwnh. 

Note that in requiring certain sequences of operations to have the same effect, we me considering the 
effect of the operations as described by the specification of the type. Thus we are concerned with the 
abstract state of X, and not with the concrete state of Its storage representation. Therefore, we may allow 
two operations (or sequences of operations) that do commute in terms of their effect on the abstract state 
of Xto be performed by concurrent actions, even though they do not commute in terms of their effect on 
the representation of X. This distinction between an abstraction and its implementation is crucial in 
achieving reasonable performance. 

It is important to realize that the constraints that are imposed by Atomicity based on the sequential 
specification of a type are only an upper bound on me concurrency that an implementation may provide. 
A specification may contain additional constraints that further constrain implementations; these 
constraints may be essential for showing that actions using the type do not deadlock, or for showing other 
kinds of termination properties. For example, the specification of the built-in atomic types explicitly 
describes the locking rules used by their implementations; users of these types are guaranteed that the 
built-in atomic types will not permit more concurrency mm allowed by these rules (for instance, actions 
writing different components of an array, or different fields of a record, cannot do so concurrently). 



104 



15 J. MuWpit NutMM 
1&1P rt« 
l«Vtoft*lOTIMttil 

to tut WW* Haw «tt mk «fc* » 




w, 



a, 
7. 



15.6 Multiple Mutates 



105 



1 . Before that crash, B also committed to the top. In this case the data read back from stable 
storage is, in fact, consistent, since it must reflect ffs changes to both the first and second 
semiqueues. 

^iT^SZ^I^lTS^^^^^ 9 ^ In either case, S aborts. Therefore, 
implementation: at the abstract level, the two semiqueues do nave the same state. 
The point of the above example is that If the objects being written to stabte storage are atomic, then the 
fact that they are written incrementally causes no problems. 

On the other hand, when an atomic type is implemented with a representation consisting of several 
mutex objects, the programmer must be aware that these objects are written to stable storage 
incrementally, and care must be taken to ensure that the representation invariant is stM preserved and 
that information is re* lost in sp*e of incrwn^ If the implementation of a type requires that one 

mutex object (can it M1) be written to stable storage before wietner (call it JM2), then the write of Mr must 
be contained in an action that commits to the top before the action that writes M? is run. 
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Syntax 



operation 



routine 



procedure 



iterator 



creator 



handler 



creator 
handier 
routine 

procedure 
iterator 

idn «proc[parms] args [returns] [signals] [where] 
routinejxxfy 
end kin 

idn - Iterfparms] args [yields] [signals] [where] 

routine JxxJy 
•nd idn 

idn - creator args [ returns ] [ signals ] 
routine _body 
end idn 

idn -handler args [returns] [signals] 
ixaitmeJxxJy 
end Idn 



routine Jbody 




{equate} 
{ own_var } 
{ statement } 




parms 




[ parm , ... ] 




parm 




idn,... : type 






1 


idn , ... : type_spec 




args 




([decl,...]) 




decl 




idn , ... : type_spec 




returns 




returns ( type_spec , 


...) 


yields 


■ ■■■■ 


yteW»(type_spec,. 


..) 


signals 




signals ( exception , 


...) 


exception 




name [ ( type_spec , 


...)] 



1 Syntax 






opkJn 




idn 




1 


transmit 


where 


fll H 


whert restriction , ... 


restriction 




idn has operjjecl , ... 




1 


Wn In type_set 
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type_set 



operjiecl 



constant 



state decl 



equate 



own var 



{ km | idn has oper_decl , ... { equate } } 

idn 

reference $ name 

name , ... : type_spec 
transmit 

expression 
type_spec 



[stable] dec! 

[ atabte ] idn : type„spec > expression 

[stable] decl ,...:» can 



idn. constant 
kJn«type_set 
idn - reference 

own decl 

own idn : type^spec > expression 

own decl , ... > caH [ @ primary ] 
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Syntax 



statement "a decl 

idn : type.spec :- expression 

decl , ... :- caN [ @ primary ] 

idn ,...:« call [ ® primary ] 

idn , ... > expression , ... 

primary . name > expression 

primary [ expression ] > expression 

call [©primary] 

fork call 

seize expression do body and 

pause 

terminate 

enter_stmt 

coenter coarm { coarm } and 

[abort] leave 

whlla expression do body and 

for_stmt 

»_stmt 

tagcase_stmt 

tagtest_stmt 

tagwaK_stmt 

[ abort ] return [( expression,...)] 

ylaW[( expression ....)] 

[ abort ] signal name [ ( expression ,...)] 

[ abort ] exit name [ ( expression ,...)] 

[abort] break 

[ abort j continue 

begin body end 

statement [abort ] resignal name , ... 

statement except { whenjwndler } 

[others.handier] 

and 



enter_stmt : := enter topactton body end 

| enter action body end 
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coarm 
armtag 

for_stmt 
if stmt 



111 



tagcase_stmt 



tagtest_stmt 



tagwait_stmt 

tag_arm 

atag_arm 

tag_kind 



::= armtag [ foraach dec! , ... hi call] body 

::= action 
| topacUon 
I procaaa 

::= for [deci,...] in call do body end 
| for [idn,...] in call do body and 

::= If expression than body 

{alaaH expression than body} 

[alee body] 

and 



expression 
tag_arm { tag_arm } 
[othersbody] 



tagteat expression 

«tag_arm { atag_arm } 
[othara .body] 



::s tagwalt expression 

atag_arm { atag_arm } 
and 

:= tag name ,...[( idn : type_spec ) J : body 

:= tagjdnd name ,...[( idn : type_spec ) ] : body 

:= tag 
I wtag 



when_handler : := whan name ,...[( deci ,...)] : body 
| whan name ,...(*): body 

othersjiandler : := othara [ ( idn : type_spec ) ] : body 

body ::= {equate} 

{statement} 
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Syntax 



type_spec 



fiekj_spec 
reference 

actual_parm 

type_actual 
opbinding 



::= null 
node 
boot 
Int 
real 
char 
string 
any 
Image 
rep 
cvt 

sequence [ type_actual ] 
«ny[type_actual] 
atomlcamy [ type_actual ] 
struct [fteW^spee....] 
record [ field_spec , ... ] 
atomlc_recofd [ fieH_apec , ... ] 
onsof[field_8pec,...] 
varisnt[fleld_8pec,...l 
atomlc_vartant { fleJd_spsc , ... ] 
Proctyps ( [type.spec ,...))[ returns ] [ signals J 
Hsrtyps (I type_spec ,...] } [ yields J £ signals ] 
cfsssortyps ([ typs.spsc , i. ])[ returns] [ signals ] 
nsmusityps ([ type_spsc , 4.. ] )[ returns ] [ signals ] 
mutsxftyps.actual] 
reference 

::= name , ... : type_actual 

"— idn 

I idn [ actual jwm .... ] 
I reference $ name 

"— constant 
I type_actual 

»= type_spec[w«h{ where opbinding,...}] 
11= name , ... : primary 



I Syntax 



113 



expression 



primary 



primary 

can @ primary 

( expression ) 

- expression 

- expression 
expression ** expression 
expression // expression 
expression / expression 
expression * expression 
expression || expression 
expression + expression 
expression - expression 
expression < expression 
expression <- expression 
expression - expression 
expression >- expression 
expression > expression 
expression ~< expression 
expression ~<- expression 
expression — expression 
expression ~>« expression 
expression ~> expression 
expression * expression 
expression cand expression 
expression | expression 
expression cor expression 

entity 
caH 

primary, name 
primary [ expression ] 



% 6 (precedence) 
%6 
% 5 
% 4 
% 4 
% 4 

% 3 

% 3 

% 3 

% 2 

% 2 

% 2 

% 2 

% 2 

% 2 

% 2 

% 2 

% 2 

% 2 

% 1 

% 1 

% 

% 



call 



:= primary ( [ expression ,...]) 
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Syntax 



entity 



nil 

true 

false 

intjiteral 

realjiteral 

charjiteral 

stringjiteral 

self 

reference 

entity - name 

entity [ expression ] 

bind entity ([bind_arg ,...]) 

type_spec ${ field , ... } 

type_spec $ [ [ expression : ] [ expression 

type_spec $ name [ [ actual_parm ,...]] 

up ( expression ) 

down ( expression ) 



■■]] 



field 
bind_arg 



.= name , 



: expression 



expression 
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Comment a sequence of characters mat begins with a percent sign (%), ends with a newline 
character, and contains only printing ASCII characters and horizontal tabs in between. 

Separator, a blank character (space, vertical tab, horizontal tab, carnage return, newline, form feed) or 
a comment. Zero or mom separators may appear between any two tokens, except that at least one 
separator is required between any two adjacent non-seM-termlnattng tokens: reserved words, Identifiers, 
integer literals, and real (Iterate. 

Reserved word: one of the identifiers appearing In bold face in the syntax. Upper and lower case 
letters are not distinguished in reserved words. 

Name, idn: a sequence of letters, digits, and underscores that begins with a letter or underscore, and 
that is not a reserved word. Upper and lower case letters are not distinguished m names and idns. 

Intjiterat a sequence of one or more decimal digits (0-9) or a backslash (\) followed by any number of 
octal digits (0-7) or a backslash and a sharp sign (\#) followed by any number of hexadecimal digits (0-9, 
A-F in upper or lower case). 

Realjiterak a mantissa with an (optional) exponent. A mantissa is either a sequence of one or more 
decimal digits, or two sequences (one of which may be empty) Joined by a period. The mantissa must 
contain at least one digit. An exponent is 'E or 'e\ opHonaRy followed by V or ■-', followed by one or 
more decimal digits. An exponent is required if the mantissa does not contain a period. 

Char_Jlterat. a character representation other than single quote, enclosed in single quotes. A 
character representation is either a printing ASCM character (octal value 40 through 176) other than 
backslash, or an escape sequence consisting of a beckslesh (^ followed <x>e to three printif^j (^aracters 
as shown in Table 6-1 or Table H below. 

String Jierat. a sequence of zero or more character representations other than double quote, enclosed 
in double quotes. 

Table 1-1 shows most of the character Hterafs aupporied by Aigus, except for the higher numbered octal 
escape sequences. For each character, the corresponding octal lleraJ, hexadecimal Hteral, and normal 
literal(s) are shown. Upper or lower case letters may be used in escape sequences of the form \#", \", 
\r, \b, \t, \n, w, \p, and \r. Note that an implementation need not support 256 characters, in which case 
only a subset of the Hterate listed wW be legal. 
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Syntax 



TaWeM: Character Escape Sequences 



■\Q00"\#O0"\N&' MOO 1 WO"®' < \200"W\|* -nsco- '*GV W*' 

33213 WW* KIT WW WWW 

WWYC M03' WC WWMC WWW? 

ZSt'SS^ wwty www www 

J»wve mos-we- ww\e- www? 

'Wvkm'VF mov-wf vnrMirAF ^aoc •\#C8' UP 

wwvg- wwrtr wwmq- mot w ws- 

WWVH"\bf MIO'WffW WWW VJIffW Wff 

•\01rwwv MirvwT wrww wvww 

^2'WA'WV MIZWA'V -\212«WA"\U' "VM? \K5A' W 

WWB'VK'V M13'WB"IC WffWW W ■V**' wc 

WWVL'V •UU'MWC-L' WW Ml? W -JcC 1 W 

■\Q15"\#0D*YM , V M15'WD"M' Wr MatfW Wff "\#CD"\*M' 

•\016"\#0E'VN' Mie'\#4E"N' ^216' WW WffWWT 

WWVO' WWO 1 WWAC WWWy 

vhcwvp M&rw-P •\22o , w\p wvwo-w 

WWVff MaTWt* TOVwrMff W\#D1'Wy 

■\022"\#12'YR' M22"WR' **2Z WW W W WT 

WWVS 1 WW'S' WWW WWW, 1 

V)24"\#14'VP M24'W4'T -N^' W4* Mr W4' VD4,' -\*T 

WWW M25'WV WWW WWW 

www mztwv www www 

varwvw mctww •otww w\#D7«wv 

■\030' via' vx- M30"W>e ^230* we'MX 1 wo- •\aoa- wr 

■\03rww Msvwr -www www 

WWA'VZ M32"MBA'7 W W MT •WWU? 

W\#1B"\Y WWT WW\r WWW 

WWW WWW WWW WWW 

WWW MSB" WD- T WWW WWW 

www ww* w w v- www- 
www -Msr^BP-j wwuj W JSJ' 

WO' WO' ' ' M4ff\N0"" WO'WQ' \k ' V!4ff •V«Eff -\a~ 

WW!' M4VWV WWW WWW' 

•\042*W'-V WWV IMr-UATW W* W X 

WW? m225S *43'WW WWW 

T044 W4 S M44' W4' 'd' "\244' "\MM' W •\344' naE*' -Mrf 

WW%' M45'WV WWW WWW' 

WW&' WWT WWW WWW 

WWV M4TWV WW? WW** 

WWT MWWV WWW WWW 

*i'WT wwt wwrw www 

WW" M62"\MA'T WWW WWW 

WWV WWV WWW WWW' 

■\054"\#2C",' M54'\#6C'T 'WMACW W4'WC"2J 

S«" 12 2? W "»WW- WWW- 

YS6 WE".' M56'\#8E"n' WWE'W W-\#EE'W 

wwr mst-wc www www- 



m 
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yawww 


*"«^Wr- '^Pg^p-- ^r 


VM'-we* 


Mtrwrv 


wrwt 


M*wr 


vmw*v 


mommtv 


smmv* 


.- Miriiiir'Y. 


VHtPVUFW 


w«vv 


•wmrw 


wmv 


•votrwr 


Mtr^trv 


v>wwt 


tmrmirv 


W1"WtV 


wnMry 


wwr? 


%nriflirif 


wrwvY 


WIMftT 


lewmrv 


vimiift 


wrmrv 


wiiirT 


i*r%Nrv 


M1V'"W /ftt *' 


WTWT 


\tfr<*irw 
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Appendix II 
Built-in Types and Type Generators 

The following sections specify the built-in types and the types produced by the built-in type generators 
of Argus. For each type and for each instance of each type generator, the objects of the type are 
characterized, and all of the operations of the type are defined. (An implementation may provide 
additional operations on the built in types, as long as these are operations that could be implemented in 
terms of those described in this section.) 

All the built-in types (except for any) are transmissbte. All instances of the built-in type generators 
(except for proctype and ttettype) are transmissbte if all their type parameters are transmissible. 
Transmission of ths built-in types preserves value equality, except for objects of type real. However, m a 
homogeneous snvironmsnt, reals can be transmitted without approximations, m a homogeneous 
environment, the only possible encode or decode failures are exceeding the representation limits of an 
Image, mutating the size of an amy or atomlc_arTay while it Is being encoded or decoded, and 
improper decoding of cyclic objects (see Section 14.4). 

All operations are indivisibte except at cads to subsidiary operations (such as \nt$simJlar within 
arrey[lnt]$s«rn/te/), at yields, and while waiting for locks. 

The specifications given below are Informal and are adapted from the book Abstraction and 
Specification In Program Development (Uskov, B. and Guttag, J., MIT Press. 1966). A specification starts 
out by giving a list of ths operations and declarations of any formal parameters tor the type. This is 
followed by an ovsrvlew, which gives an Production to the type and if necessary defines a way of 
dsscribing ths type's objects and their values. Fottowtog this the IndMduaJ operations are described. For 
sach operation there is a heading and a statement of the operation's effects, in the heading, the return 
values may be given names. Ths effects section describes ths normal and excepttonaJ behavkx of the 
operation. The effects given are abstract, that is they are described using the vocabulary (or modal) 
defined in the overview section. For example, objects of type W are cieecribed using mathematical 
integers. Thus arithmetic expressions and comparisons used m defining Hit operations are to be 
computed over the domain of mathematical integers. 

An operation that (abstractly) mutates one of its arguments lists the arguments that it mutates in ths 
clause following the word modifies. An operation is not slowed to niutate any objecte, •*»<* tor those 
l&ed in the modifies clause. (For ths built-in mutable atomic type geiierstore, rr»d»toatkw wily refer, to 
the sso^srtiaJ state; rdoee not refer to chaiiges In when 

an argument, say a, is mutated, it is often necessary to oesenbe Is state at the start of the cal as well as 
its final state at the end of the can. We use ths notation a^ tor as state at ths start of ths cal and the 
notation a^, tor its state at the end of the call. 

Some operations of the built in type generators are only defined if the type generator is passed 
appropriate actual routine parameters (see Section 12.6). For example, the copy operation of ths array 
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type generator, is only defined if there is an actual parameter passed (explicitly or implicitly) for the type 
parameter's copy operation. Thus array(lnt}$copy is defined but airayfanyJ$copy is not defined. These 
requirements are stated in a requires clause that precedes the description of the operation's effect. The 
type of the expected routine is also described; remember that the actual operation parameter can have 
fewer signals (see Section 6.1 and Section 12.6). 

By convention, the order in which exceptions are listed in the operation type is the order in which the 
various conditions are checked. 

Operations with the same semantics (for example, nutgeoua/ and nuUUimUv) or that can be 
described in the same way (for example, toga*/ and lnt$suD) are grouped together to save space. 

In defining the built-in types, we do not depend on users satisfying any constraints beyond those that 
can be type-checked. This decision leads to more complicated specifications. For example, the behavior 
of the elements iterator tor arrays Is defined even when the loop modifies the array. 

11.1. Null 

null - data type Is copy, equal, similar, transmit 
Overview 

The type null has exactly one, immutable, atomic object, represented by the literal nil. Nil is 
generally used as a place holder in type definitions using onsets or variants. 

Operations 

equal - proc (n1 , n2: mill) returns (bool) 
similar - proc (m , n2: null) returns (bool) 
effects Returns true. 

copy - proc (n: null) returns (null) 
transmit - proc (n: null) returns (null) 
effects Returns nil. 

11.2. Nodes 

node - data type Is here, copy, equal, similar, transmit 
Overview 

Objects of type node are immutable and atomic, and stand tor physical nodes. Implementations 
should provide some mechanism for translating a node "address- into a node object and vice 
versa. (However, these do not have to be operations of type node.) »***««««» 

Operations 

here - proc () returns (node) 

effects Returns the node object for the caller's node. 

equal - proc (m , n2: node) returns (bool) 
similar - proc (m , n2: node) returns (bool) 

effects Returns true if and only if n1 and n2 are the same node. 






copy«p«ac(fi: 
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HA 

boot . tfaia typtlt and, or. not, «qutf. 



Hit 



and-pfoc(b1,h8 



BpGVVwt 




M.4. hUtgiri 

tat-drtatyptteadd. 
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minus *■ prao (& tat) 

•MtQlt HllW 
dlv-proc(x, yjtat) 

mod ■ proe (x, if: 

pow«r-p«c<x,y:tat> 



• fit mut would to outttit ttw 




By^fMiptWf|ptft#4C. 



it 

flt ■ 







copy »pwo fr: tat) WtaW p|) 
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trantmlt-proc (x: bit) retume (y: int) signats<faiiure<strlng)) 

•^2L R0 !!11^ y such that x - y or signals faOun If x cannot be represented in the 
implementation on the receiving end. 

11.5. Reals 

real - data type is add, sub, minus, mul, div, power, abs, max, mm, exponent, mantissa, I2r, r2i, 

trunc, parse, unparse, It, le, ge, gt, equal, similar, copy, transmit 
Overview 

IIVZZJ^^ *i« used tor appioximats or floating 

point arithmetic. Reals are immutable and atomic, and are written as a mantissa with an optional 
exponent See Appendix I for the format of real Items. ^ 

Each implementation represents a subset of the real numbers in: 

D . {-realjnax, -realmln} U {0} U {real mm, real max} 
where ~ "" 

< realjnin < 1 < real max 
Jkjmbers in D are approximated by the implementation with a precision of p decimal digits such 

Vre D Approx(r) € Real 

VreReal Approx(r)-r 

Vr e D - {0} | (Approx(r) - r)/r| < 10 1 "P 

Vr,s e D r s s ==» Appiox(r) s Approx(s) 

Vr e D Approx(-r) « -Approx(r) 

^JSTn^nZT^ 1 " "SS^IL'T (exi,0,,y <>"•<**«* *«o. before the decimal 
SpSnel? A**.**** digits of mantissa and no more than Exp__wk*h digits of 

^r^t^^SSL 8 "^? 10 "^ the re8u * * a o "***** »•» outsWe of D; overflow 
occursrf the magnitude exceeds nal_max, and unoeritow occurs If the magnitude is less than 

Operations 

■** " 22ili! , ^ : nm) , * lum • {roa, > • , * n • , • «"•**». underflow) 

•fleets Computes the isum z of x and * signals overflow or underflow* z\sou\sUeotD, as 
explained earlier. Otherwise returns an approximation such that: «**»<» u, as 

(x.y a v x,y s 0) =* add(x, y) - App»ox(x + y) 
add(x, y) . (1 + e)(x + y) |e| < 10W> 

add(x,0).x 
add(x, y) . add(y, x) 
xsx'^aooXx.yJsaddfx'.y) 

81,5 " VOli*'? "* -1 ^ ,1,um • <»•*) ■*"■• (overflow, underflow) 
slfscts Computes x - y, the result is identical to «**>, -y). 

minus - proe (x: rest) returns (reel) 
effects Returns -x. 

mul " PJS^J** y: r,i,) p,,l,,,, • (r,-, > •fc 1 * 11 (overttow, underflow) 

effects Returns approx{x*y)- signals otwflcwor underflow If x*y is outside of D. 

dlV " ^JL^l W***** («■•) «Hmare (isro_dMds, overflow, underflow) 
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power - proc (x, y: ran) returna (rati) 

^^ eigne* (zero_dMde, complex_re»u*, overflow, underflow) 

•Htcttlf x m o and y < 0, signals zt»o_o*tff. M x < and y is nonintegral, signals 

oofr^__««rft Otherwise returns an approximation to #, good to p significant digits; 

signals overflow or wiotrflowtfjf is outside of D. 

ab6 - proc (x: raai) ratume (raal) 

affaeta Returns the abaoluta value of x. 

max - proc (x, y: raal) ratumt (raal) 

affaeta If xay, than returns*, otherwise returns y. 

min - proc (x, y: reef) ratume (real) 

effects If x*y, then returns x, otherwise returns y. 

exponent - proc (x: raal) retume (Nit) signets (undefined) 

affaeta If x - 0, signals undefined. Otherwiee returns the exponent that would be used in 
representing x as a WeraJ in standard form, that is, returns 
max ({I | abs(x) a 10»}) 

mantissa - proc (x: raal) ratumt (rati) 

effects Returns the rnanbtsa of x when represented in standard form, that is, returns 
appflMt'x'lO*), where e - •xponmUx). if x - 0.0, ratumt 0.0. 

i2r - proc (i: Int) ratumt (rati) eigne* (overflow) 

tffectt Returns appraxM; signals overflow If /is not in D. 

r2i - proc (x: rati) ratumt (tot) tfgnttt (overflow) 

effects Rounds x to the nearest integer and toward zero in case of a tie. Signals overflow if 
the result lies outside the represented range of integers. 

trunc - proc (x: rati) ratumt (tat) eigne* (overflow) 

tffectt Truncates x toward zero; signals overflow if tat result would be outside the 
represented range of Integers. 



P 8 ™ ZE£J£ 8trii,rt mMm {m/ l **"* **J***. «*w*aw. unttrftow) 

tffectt Retume appro**,, where lis tat value rsprcoomedby the string g (see Appendix I). 

otherwlst signals bmdjormat Signals underttowor overflown 7 is notinD. 
unpar se ■ .pro c (x: reel) retume (string) 

affaeta Retume a real Weral such \ha\ ptrstiunparstix)) - x. The general form of the HteraJ 
is: 

[-]/Jtatt/ fstf[.t±x Md] 

Leading zeros in i/ fetf and trafetag zeros m fjfc*/ are suppressed. If x is integral and 
within the range of rapraeeiatd integer* taenfjlitf arid a^ » 

i£P£? F*?^! P *?2L±!!!Z£ m * '"• *™^^ i^ ****** no wftomit 
SSLA* " 1 B L2ff£ , ' , * a * , > * *L"*«I. »»n it exponent is not present. 
Otherwise the tteraJ is in standard form, wihExp.wfotadfcts of exponent. 

it - proc (x, y: real) ratumt (boot) 
le - proc (x, y: reel) ratumt (boot) 
ge - proc (x, y: reel) retume (boot) 
gt- proc (x, y: reel) retume (boot) 

effects These are the standard ordering relatione. 

equal « proc (x, y: raal) ratumt (tool) 
similar -proc (x, y: raaf) ratumt (boot) 

effects Returns true if x and y are the same number; retume flaltt otherwise. 
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II.7. Strings 

string - data type la c2s, concat, append, substr, rest, size, empty, fetch, chars, indexs, indexc, 

s2ac, ac2s, s2ac, sc2s, It, to, ge, gt, equal, similar, copy, transmit 
Overview 

Type shlng is used for representing text. A string is an immutabis and atomic tuple of zero or 
more characters. The characters of a string are Indexed sequentially starting from one. Strings 
are lexicographically ordered based on the ordering lor character. v ^* 

itSffrSSt *J0!*£„ !? „' *"*»"» « t™ <* ™» character representations enclosed in 
used within string literate. No string can have a size greater than ini mar however an 

$eSs^im«£ ^ containing more than the maximum number of characters, tr2 
Operatlone 

c2s - proc (c: char) ratuma (string) 

effecta Returns a string containing c as Its only character. 

concat -proc (si , s2: string) returne (r. string) algnale (limits) 

eflscie Returns the concatenation of st and a?. That is, 4f>"E4 for / an index of si and 

SpSSiSSSf "" ind0X * **" s,flf ^*^* rwo ^ tatoo,ar 0«to f t"« 

append - proc (s: string, c: char) ratuma (r: airing) signals (limits) 

•""^Ff -5?!?!* a f* **• havin 8 the characters of a in order followed by a That is, 
/f.s/ze(s)+1]«c. Signateflmte if the new string would to too la^ 

substr -proc (a: string at: kit, _cnt: Int) returns (string) signets (bounce, negative size) 

**?£-* J* 1?' ***** «VsW_s*» If af < 1 or af > efea(s)+l, signals sounds. 

string contains /ri^cm,*ize~aM) characters. For example, 

substr ("abcdef", 2, 3) - "bed" 

substr ("abcdef", 2, 7) - "bedef" 

substr ("abcdef", 7, 1)-- 
Note that if min(cnt, size-at+1) - 0, substr returns the empty string. 

rest - proc (s: string, i: Int) ratuma (r: airing) signals (bounds) 

*l3X5l U !!l^ ,< *JZl > *? b & * ,: oiww ^ "**"* » «WnP whoss first 

Note that if /-s^sM./asf returns the empty string. 

size - proc (s: string) ratuma (Int) 

effects Returns the number of characters in s. 
empty - proc (s: string) ratuma (tool) 

effects Returns true if s is empty (contains no characters); otherwise returns falsa. 
fetch -proc (s: airing, i: int) ratuma (char) signals (bounds) 

sffecte Signals bounds* /< o or /> afeefs); otherwise returns the /th character of s. 
chars - Iter (s: string) yleMe (char) 

effects Yields, in ordsr, each character of s (i.e., s{1], s|2}, ...). 
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indexs . proc ($1 , s2: string) returns (tat) 

offsets If *T occurs asa substring In a2, returns the least index at which sf occurs. Returns 
if 81 does not occur In standi if si Is the empty string. For example, 
indexafabc", "abcbc") - 1 
IndexsTbc", "abcbc") - 2 
indexsT, "abode") - 1 
mdexsCbcb", "abode") - 

indexc - proc (c: char, s: string) returns (Int) 

affects H c occurs hi a, returns the least index at which c occurs; returns if c does not 
occur in & 

s2ac - proc (s: string) returns (arrayfcnar]) 

effects Stores the characters of a as elements of a new array of characters, a. Ths tow 
bound of the array is 1, the size is $lze(s), and the Ah element of the array is the Ah 
character of a, for l£/£afee(s). 

ac2s - proc {a: arrayfchar]) returns (string) 

effects This is the inverse of s2ac. The result is a string with characters in the same order 
as in a. That is, the Ah character of the siring is the (/4srray(cnsr]$/oti<a)-l)th element 
of a. 

s2sc - proc (s: string) returns (sequencefcharD 

effects Transforms a string into a sequence of characters. The size of the sequence is 
size(s). Trw Ih element of trw sequence Is the Ah character of s, fori ^ /$5tee(s). 

sc2s - proc (8: eequence[charD returns (string) 

effects This is the inverse of §2sc The result is a string with characters In the same order 
as ins. Thaiis,theAhclwa<4erofthestrirtglitheAhelernentofs. 

It - proc (81, s2: string) returne (boot) 
le- proc (81, s2: string) returne (boot) 
ge - proc (si, s2: string) returns (boot) 
gt - procjst, s2: sttlng) niurns (boot) 

effects These are the usual lexicographic ordering relations on strings, based on the 
ordering of characters. For example, 
"abc"<"aca" 
"abc"<"abca" 

equal - proc (s1 , 82: string) returns (bod) 
simila r -proc (si , s2: string) returne (boot) 

effects Returns true If s1 and s2 are the same string; otherwise returns false. 

copy - proc (si : string) returne (string) 
effects Returns si. 

transmit . proc (si : string) returns (string) signals (faaureistftog)) 

effects Returns si. Signals fttfure only if »y is not repreeentabie on the receiving end. 
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II.8. Sequences 

saquenca - data type [t: type] Is new, e2s, fill, fW_oopy, replace, addh, addl, remh, reml, concat, 
subeeq, size, empty, fetch, bottom, top, elements, indexes, a2s, s2a, 
equal, similar, copy, transmit 

Overview 

Sequences repressnt knmutabie tuples of objects of type/. The elements of me sequence can be 
indexed sequentially from 1 up to the size of the sequence. Although a sequence is immutable, 
the elements of the sequerx* can be mutable objects. The state of such mutable elements may 
change; thus, a sequence object is atomic only if its elements are also atomic. 

Sequences can be created by calling sequence operations and by means of the sequence 
constructor, see Section 6.2.8. 

Any operation call that attempts to access a sequence with an index that is not within the defined 
range terminates with the bounds exception. The size of a sequence can be no larger than the 
largest positive Int (tof_max), but an Implementation may restrict sequences to a smarter upper 
bound. An attempt to construct a sequence which Is too laige results in a Onto axception. 

Operations 

new - proc ( ) returns (sequence^) 

effects Returns the empty sequence. 

e2s . proc (elem: t) returns (sequence^]) 

effects Returns a one-element sequence having e/em as its only element. 

«H - proc (cnt: Int, elem: t) returne (sequence^) signs* (negative size, limits) 

effects if enf < 0, signals negaHve_size. If otitis larger than the maximum sequence size 
supported by the implementation, signals Jttnas. Otherwise returns a sequence having 
cnt elements each of which is ohm 

filLcopy . proc (cnt: Int, elem: t) returne {sequence^) 

•I0nals(negative_8ize 1 lirr*«ja«ure(str1ng)) 
requires t has copy: proctype (t) returns (t) eignele (faHure(string) 
effects If cm < 0, signals negatft*_abe. if cnt is bigger man the maximum size of 
sequences that the implementation supports, signals *nte. Otherwise returns a new 
sequence having cnt elements each of which is a copy of stem, as mads by ffecpy. Note 
,ha L*?£ y * cased cm times. Any mure signal raised by ficopy is immediately 
resignaHed. This operation does not originate any failure signals by itself . 

replace - proc (s: sequsnesft], I: int, stem: t) returns (sequenceftl) ■ajiisJt (bounds) 

sffectalf *<1 or/ > n^s), signals bound: Otherwise returns a sequence with the same 
elements ass, except that efcm is in thsah position. FbrsKampts, 
replace(eequencennt}$(2,5] 1 1,6)- sequenceftntfte, 5] 

addh - proc (s: sequsnesft], stem: t) returne (r. sequenceftD signs* (smks) 

effects Returns a sequence with the same elements as * toftowed by one additional 
element, elem. That is, /fJM«l for / an Index of s, and rfsfeefeMJ-e/em If the resulting 
sequence would be larger than the implementation suppon^, signsJs «mns. 

addl - proc (s: sequsnesft], eiem: t) returns (r sequenceftD signals (limits) 

effects Jtetums a sequence having efem as the first element foeowed by the elements of s 
in order. That is, ffl]-efem and <f4-*M] for / - 2, .„, atzo(r). if the resulting sequence 
would be larger than the implementation supports, signals *n«s. 

remh -proc (s: sequsnesft]) returns (r. sequence^) sfgnaie (bounds) 

^• ctt Jf* te «» n Pty.»ipnals bounds. Otherwiss returns a sequence having ail elements of s 
In order, except the last one. That is, sfeeftJ-sfeefeH and 44-44 for /- 1 sizefsH . 



mm 



mmmmm 

129 



mmmmmtmmtmmmmmmmm 



its 




S2t«pW|R 



•quaUpraetfl.tfti 



i3B3 






■*4»a^#i 



'<■»* TlwtNtctof 




n-;*^.. .. 



130 BuW-ln TypM and Type Generators 

copy - proc (s: sequenceft]) returns (ssquenceft]) eigne* (fa«ure<etr1ng)) 
raqulrai if has copy: proctype <t) raturna (t) algnale (faaura(atrtng)) 

•^STi^SSirS it^2J^!PfJ^£?? ** • l ^»^*» cx>pia» of ttio atiawnertts off *. The effect is 
equivalent to that of the following procedure body: 

y:qt:-qt$new() 

tor e: t In qt$elemsnts(s) do 

y :- qt$addh(y, t$copy(e)) raafgnal failure 



return (y) 

transmit -proc (s: eequenceft]) raturna (eequence(t]) algnafa (faikjre(strlng)) 

raquwee t has tranamit 

effects Returns a sequence having as elements transmitted copies of the stomsnts of s m 
the same order. Sharing among elements is preserved. Signals failure if this cannot be 
represented on the receiving end and also rssignats any tafcrec from fttranemK. 

II.9. Arrays 

array - data type [t: type] la create, new, predict, fm, fiH_copy, addh, add), remh, reml, 

8et - tow, j!! m ' ****' ,eten - bottom ' ^ em P ,v ' 8tee - tow, Wgh. elements, indexes, 
equal, similar, similar!, copy, copy1, tranamit 

Overview 

^SUSJU^SS! ° b|e ? te that re » xe8ent W 08 <* etomente of type t that can grow and shrink 
ffiSf - ?" ??*« n ^ , ^ oonrt *<*^ The 

atarToSect 8 fc1dexed 86qu6f * i a ^. *artlng from the tow bound. Each array also has an identity 

J,™**^*"^^ Theycan 

arbitrary number of Initial elements, see Section 6.2.9. 

OP*^^. W andsfee return the cvn^ low and high bounds and size of the array. For 
V^SS^^i^^^*^ 9 ^^' These are rotated by 

S^Ste SSSL'Jif 1 ^ 00 ^^ JS^ *"** hioh bound ^ «" arra y- •^^ te a ctef*nod element, a<4- The 

bounds exception is raised when an attempt is made to access an element outside the defined 
range . Any array must have a tow bound, a high bound, and a size which are al tooJ I inteoere 
An .r.ptemertatton nrwv restrtet thsss to som^ 

exce^toV^ 

Operations 

create - proc (to: Hit) returns (arrayftj) signals (limits) 

effects Returns a new, empty array with tow bound to. UmUs occurs if the resulting array 
wouWnot be supported by the implementation. * y 

new - proc ( ) raturna (arraytfl) 

effects Returns a new, empty array with tow bound 1 . Equivalent to create(1). 
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store - proc (a: array[t], i: Int, etom: t) signals (bounds) 
modifies a. 

effects H / < tow(a) or / > high{a), signals bounds-, otherwise makes elem the element of a 
with index /. 

fetch - proc (a: arraytt], i: mt) returns (t) signals (bounds) 

offsets If / < tott(a) or / > Nghta), signals tounda; otherwise returns the element of a with 
index/. 

bottom - proc (a: arrayft]) raturra (t) stgnala (bounds) 

affacts If ais empty, signals bounds; otherwise returns aftoM<a)]. 

top . proc (a: arrayftD returna (t) signs* (bounds) 

affacts If a is ampty, signals bounds; otherwise returns af/i&ftfa)]- 

empty - proc (a: arrayft]) returns (boot) 

effects Returns tmsif a contains no elements; otherwise returns false. 

size - proc (a: arrayft]) returna (mt) 

affacts Returns a count of the number of elements of a. 

low « proc (a: arrayft]) returns (bit) 

effects Returns the low bound of a. 

high - proc (a: arrayft]) returns (Int) 

offsets Returns the high bound of a. 

elements - tor (a: arrayft}) yields (t) signals (faNunKstrlng)) 

affects Yields the elements of a, exactly once for each index, from the low bound to the high 

bound (i.e., bomtn{*pJ fqpt*^)). The elements sis fetched one at a time, using 

the indexes that were legal at the start of the call, if, during the iteration, a is medHed so 
that fetching at a previously legal index signals bounds, then the Iterator signals failure 
with the string TMunds". The Iterator is owistole at yields. 

indexes - Her (a: arrayft]) yields (Int) 

effects Yields the Indexes of a from the tow bound of a*, to the high bound of a™. Note 
that Indexes is unaffected by any modifications done by the toop body, it is dMsfele at 
yields. 

equal - proc (a1 , a2: arrayft]) returns (bool) 

affacts Returns true If a1 and a2 refer to the same array object; otherwise returns false. 

similar - proc (al , a2: arrayftj) returns (boot) signals (fasjre(stiing)) 

requires j has similar: proctype (t, t) returne (boot) signals (faflure(strtng)) 
affecta Returns true If al and a2 have the same tow and high bounds and if their elements 
arepaiiwisesin«arasctotenninedby««<m«ar. This eSeot of this operation is equivalent 
to the following procedure body (except mat this operation is only divisible at calls to 
tbslmllai): 

at - arrayft] 

If at$tow(a1) — at$tow(a2) cor at$size(a1) — at$size(a2) 

than return (false) 

and 
for i: Int In at$todexes(al ) do 

If ~t$aknilartal(l], a2f(]) than return (falae) and 
rsslgnal f aftura 
except when bounds: signal fa*jre("bound8") and 

and 
return (true) 
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sknaan - proc (al, «2: srraytfD returns (boot) signal* (fa«ure<strlng)) 

rsqujss /hat equal: proctypa (t, t) Mums (boot) signs* (faNurefstrlng)) 

•™ ctt F T?H* ^ J a1 "* ** "•*• *• •*"• •*» "* Wgh bounds and if their elements 
arepairwtos^alasdrtsfrrtn^by^aQua/. TNs opsration works the same way as 
s^^,exc^that«egi^isus^instesdo*J»a*ti«sr y 

copy - proc (a: array^D returns (b: srrayft]) sfgnaJs (faiui«<strlna)) 

rsquirss /hss copy: proetype (!) returns (|) stgnssi (fsHurefstrtng)) 

■^SlSS"!!? ISl^i^lL?* «^ ^ ^ »^ bounds ss a snd such that each 
elw^^oontslns tfcqpMsM). Ths effect of this opsration is equivalent to the 
fo*^nobc<hr(exceptthst*i8«>n^dis^stt^stcsisto»^: ^ 

b: srrayft] > srrsyft)$copy1(a) 
tor i: int In srrayft)$indexe*(a) do 
b(i]>t$copy<a(i]) 
rssignsi failure 
exespt when bounds: signs! faJursCtxHmds-) end 



return (b) 

copyl . proc (a: snay[tl) returns (b: arraytt]) 

offsets Returns a new array b with ths same low and Ngh bounds ss a snd such that each 
element fi(4 contains the same element ss all 

transmit - proc (s: srrayft]) returns (b: srrayft]) signals (fsHursfstrfng)) 
requires f has transmit w 

effects Returns a new array b with ths same tow snd Ngh bounds ss a snd such that each 

!!5!!!!!l51 c !! n ^^ tm ^^ 8harin o "ft*** *• ***** of a is 

222?* ^ 2^^*'^ l6o «^^' , ^»^ntodonmsr^ 

O?^ 1 ,"* tlemtrt * a ■^ Ww °* V «>um«« bounds sxcssptton siid rsslgnals any 
fetfuresignsls raised by ^transmit. ^ ' 

11.10. Atomic Arrays 

stomlc_ar«y -drtatypsj [t: type] Is create, new, predict. fW, fi_eopy, sddh, add), remh, rami, 

IfoJ ^^•^•*?J' bo ^.top.eiiipty,slae,low,Wgn^ elements, indexes, 
aa2a, a2aa, squsJ, Hmftar, simiarl , copy, copyl , transmit, 
test_and_raad. test_and._wrfte, canjesd, csnjwrlts, read_tock, write Jock 
Overview 

i^^!St^ m !^ ,g ^J U1 ^ ** «*""•* «*tos of elements of type f that can 
S12? JSr?^ 1 ^^- S?\ « tomic -»«y , « <«•*»••*■» *•» consists ofthl. tuple of 

wwbound. Each atomfcarray also has an Identity m an object. 

Atoirfc^a^ can be created by MtfHrigrt copy, and 

SSLJS^JS^S!^ 'IZ^JZS* J*"**-*™* constructor, whfch spsXlK 
array tow bound, and an arbitrary number of inNial stomsnts, sse Section 6.2.9. 

Operations ton; high, and size return the current tow snd Ngh bounds and slzs of the 

^~%2L ^SJSPJ"* *' *«* * ■*• ~^ofeiemenNtoa.wNchiszcroifais 
empty. These are relatsd by the equation: Ap/W - Jbwfa) + sire(a) - 1 
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Operations 



•M "^SS^ ttemic_array, thw is t coined atom, 

«M. i ne oountm txcaptton to rate+d whit an Mta*^ % m^rin to mrrmn* mn *i*m*r* i-mt^M- thn 

CCS- *ffl^^^^^^~^^« 

terminates with a Ante exception 7*»* exception ^^ ^^ ^^ ranfle 

slffi^^eTJI i ^ lB ^* tB ^ Ths toewng rules are described In 

k to li^?- tt te ■" "* * a I* 00 ** 8 that ■ not in an action attsmpts to test oroSatoatock- 

when this happens ths guardian running ths process waTcmsfc* defined ha2/ 11 ^L 

operation that (to the norm* «,) oSESt mJ^JTJSSn &tt !&£*$! 



create-^proc (tojnt) returns (a:atomlc_arTay{t]) signets (Mmas) 

^y.yyTf new ' amply «te^_t*ray iwibw bound to. /.ftnss occurs if the 
r^JUr^a^^ 

new -proc() returns (atomic array[t]) 
affects Equivalent to croifeO). 

P ^ W -l£2f£L cnt: ,nt) r,lum • < a: *^-""ll§ •H** M 

^^f^^T'^J^-^*^***"** Ths cassr obtains a read 

te a prediction of how many actons or adbft are fcety to be perfemisd on tote now 

am. umtts occurs if the resulting atomic array would not be suooortad tw trw 
Jnplsfiwtoaton because of its Initial low bound* (not Dseaurn Tof U pradttsd ate* 
because of the predfctsd high or tow bound). «•"«■•«« preawea size or 



m *"!*<■?• "* : **> *""• *> W*"" derate amyftj) signs* (negative size totts) 

affects if enf < o. itana* wm^» «/« ^-q^TlLi rr^TJ!5T?r 8g l'.T m8 / „ 

size enr ^JE*Z*mZ~^J?LJ!r?T£* "^ •te^_««^ ^ tew bound to snd 
wzecntana wen atom as each element; I this new atoms) array would net be euoooftad 
by the Imptenw^ion, signals *»*.. TheeaeVobtastoTrea^^ 



fHLcopy . proc (to, cnt: Int. stem: t) returns (atomic arrayftl) 
afgnass (negative size, Hmts, faHuWatrtoa)) 
raqulraa f has copy: practype (t) retuma (t) signs* fetiureistrtna}) 
effects The effect is ma Mr except that ^ a^Toopto7S«Sas if «* < o «j««*. 

thTrcsuTCm^ 2E*5 

dc^oriSstolSratt^^ Tr^oparatton 

SfKKs^ Ktnanmwan^oatinotb.raprewrmKlby 

-d * ".£2L <a «*^J™»yffl. atom: t) signals (Units) 
moermeea. 

'"taam^Saf^K 

^^mSwlJlSfnS^^!^ 

W7W5. umerwtse extends a by 1 in toe high dN ct ton . and atom <kn m u-My, 

element. That is, a^^/i^Ka^-ll - a^tom. ^^ •*» ■• am new 



i A-wfc*,-:<" ,-.' ;.*■■:■ '■<' fy? f£> i-V.WS^a:*a*i? '-•■ 



- ^/«^#HH«^^^ 
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addl -PW^«**"L«"((ft •«**: t) •fcmtt (tmtte) 
modlflM j. 

-> %2fl!? n, JS ,l, JS^* »•<•««•••«••• «•"•«■ www owMi.«iito» bound. 
£S£* *L*?V ,ut y, 1* L™** ****** * *» m^OmnM UI o ii, than stands frnte. 



remh "JESii: i*™*-""*® Mtun » » ••P** (bounds) 

•W^Ob^tygtocl^^if Otaanalsashilnksaby 

ramovtag in high atomant. and mums tht rsmovad atomant. That it, NghCa^j - 

Wgnt^J-l. ^^ 

rami - precjc atomlc_arraylt]) ratuma (t) atgnala (bounds) 
modlflM & 



•«ao»Ob^ a wnta look on a. if a ia an«iy, atpiak teunda. Qta a n atoa ahrtnka a by 
ramovtag as low atoms*, and ratuma tha rsmovad atomant. That la. toaK^J - 

setjow . proe (a: atomte.arraytt], to: bit) atgnala (smite) 
mortillM m 

•■■■waawaaaaw as* 

the ^mnt^n, than signaJ. imrtr OftamftaaTmaaltaa tha law and ia^^mdsof 
a; tha now tow bound ofatofcandthanawhtgh bound to AMta-J - 



trim " 'SSi* ■^'©-•"•m ■>. cnt: kit) atgnala (nagafw.stea, bounds) 
two oro aa a 

•«a^H^<o,slor^n< v ^_*fw^ooas riot oblain any look.. Othamtoa obtains a 
"ft* 1 ?* ?* **<*«4«*>>hm4+1.*9mmm*. Oftarwtoa.modtoasaby 
^moving tol_t tom>nts w tn ind sx < to c * grsatsr tha n or a** ta *»cnt, •» nsw low 

tilmfa, 2, 2) rsauas in a havta vaaja aaaaato aaaaveatMB 2. 31 
trimta, 4, 3) mauls in ahavtog v s k ii taBaa to_am^|mt) $ t 4: 4, 5] 

"^ "i2££ ■'**-■"«•«. I: «"t. •»«*: t) a*p«ta*baiihoa) 
modlflM «t 



.nakas^ti.^^ " '* **«' *"* *»"* "^ 



feteh . Jjrocja: atomte an*yffl, l: tat) ratuma (t) akjnala (bounds) 

^SSJ Vi£S?JLil**^ • ,B,,,I| *"*■* *«<<*»» «**"• «» •«•«««« of a with 
Wax /. Always obtains a road took on a 



botto m -"P ff P c * a: ****J**iM itauiM ft atgnala (bounds) 

'''to&Zf ****'**** teund * *"*^ »^ *^*tt Always obtains a read 



top - proa (a: atomte_array(tD ratuma (t) aignala (bounds) 

•^^*«^>*»^*m^o »^^ Always obtains a road 



OTW 'jypc (a: atomte_array{t]) ratuma (boot) 

"""oaaalnaTlsaffl In ailhar case 



slze " 52!i? : •*"*_«*»¥!© nMurna (tat) 

aftaeta Returns a count of tha numbar of atomsnts of a, obtains a road took on a. 



1 *• Buttt-m TypM and Type Generators 

low - proc (a: atomlc_array{tD returne (Int) 

affacta Returns the tow bound of a, obtains a read lock on a 

high - proc (a: atomle_array(t]) returns (bit) 

affacta Returns the high bound of a, obtains a read took on a. 

elements - Mar (a: atomte_anayffl) ylaWa (t) aignaia (falure<atrtng)) 

affacta Obtains a read took on a and yields the etoments of a, each exactly once for each 

index, from the tow bound to me high bound (Lav fcotp^O lop<0>- The 

elements are fetched one at a time, using the iralaxM that wefe»egai at trw^aVt of the 
can. if, during the aeration, a la mooHed so that fataMag at a prevtouely legal index 
signals bounds, then the fterator signals <a*ur» with the strirtg "bounds". The iterator is 
divfeibie at yields. 

indexes - Her (a: atomic_array(t]) yietde (kit) 

effects Obtains a read took on a, than yields the Indaxaa of a from the tow bound of a,, to 
the high bound of a^. Note that Max* ia unaffected by any mooWaatons dorw bytbe 
toopbody. it ia dMstoie at yields. 

aa2a - proc (aa: atomJc_arTayft]) returne (arrayft]) 

affacta Obtains a read took on aa and returns an array a with the same (sequential) state. 

a2aa - proc (arrayftj) returna (aa: atomic atrayft]) 

effe«aReturrwanatomfc_arrayaawithme8amestateasa. Obtains a read lock on aa. 
equal - proc (al , a2: atomlc_aiTayftD returne (boot) 

affacta Returns true If at and a? refer to the tame atomic array object; otherwise returns 
false. No locks are obtained. ~ ^^ 

similar - proc (al , a2: atomte_arraytt]) returne (boot) aignaia (taiiure<atrtng)) 
requiree t haa similar: proctype (t. t) returne (boot) eigne* (failure(atrmg)) 
affacta Returns true K al and a2 have the same tow and high bounds and IT their elements 
are pairwise aimaar aa determined by afcensar. See me desonptton of the aMUar 
ojperaton of array for an equivatont body of code. Thia operation is dMeibto at cats to 
$8mHar. Read tocka are obtained on at and m2, in that order. 



sinrulart - proc (al, a2: atomic_array{tj) retuma (boot) atone* (facetting)) 
laqutroa f has equal: proctype (t, t) resume (boot) atgasse (failure(atrtng)) 
affacta Returns true If al and a? have the same tow and f^ oourtos and V their elements 
are pairwise equal as determined by *eou* Thto operation works the same way as 
simfar, except that aUqual is used irwtead of *s*n«ar. Read tocka are obtained on al 
and a?, in that order. 



copy - proc (a: atomte.arrayttj) retume (b: atomte_arrayflJ) aignaia (faaure(atrmg)) 
roqutfw if has copy: proctype (t) returne <t) stone* (fatfcre<aMng)) 



offec* Returns a new atomic i array wen the eejne tow e«d Mgh bourids « a and such 
that each element 44 contatos DcotMM- See the deentefen of the copy operation of 
•frayfor an equivalent body of code. Thia operation is dMstoie at cads to ftcosy, and 
obtains read looks on a and b. ' 

copy! - proc (a: atomtc_arrayft]) returne (b: atomic arratf® 

affacta Returns a new atomic_array b with the same tow and high bounds as a and auch 
that each element oft contains the same element as 44. Read locks are obtained on a 
ando. 
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xnnm HiS^t { SXSmir m i * un,t (b: • tomlc - a,fl yp» ■*■■»• m*twm 

^^IXZSZ^lZZ^ "■"•J^fV* 11 bourxte «• »nd such that each 
2S^SH^!^^i^T ,,tt f dawo, ^ »^ k^ «• obtained on a and b. 

"*"•«** oniht reesMng and or » f^eNnfl an stomsfit at a tsgal Wax ol a« causes 
abourxtesxcspttonandresigrwlsaiiy/a^ v " 

test_ano^ - proe (aa: atofnte_array[tl) mums (booi) 

^SlSiJ^Sil^Sii^^ *«"lo*itobtaJnsd,ret«jn*ti^ 

£2L ¥ c *S nrtan i 1h0opw,,aon '^ urn,,il »- "^0P««tend8aariot-*arforalcck 
n^^TS2.'?2,22r" ««• bck oouw be obtained, la^mVS 

test.andwrte -prec (aa: atomto.arrayft]) returns (boot) 

"^I r 55l2^ a JT!15if n "- tf ^^*<*«^.«^trua;ott»e«^ 

b£ ^lf^f£i^S^^S? , J? ,i - J?«P*^<^"*Wferslock. 
Evenll the wearing action "knows' that a lock could be obtained, Wat may be 

<»nj»ad« proc (aa: atomlc_arrayft]) returns (boot) 

*TgJJ*» n> t 2?J!« J^ 10 ? a** *• o*** 1 ^ w» «• «*houl waiting, otherwise 
2EesXJ£K.U^ Evenltheexecu^adtonTet«i^^ 

oTre^^S^ 1 !!^ 

Z£*SL fi^L^J ?25=*2[ 1** *"•' "* WoniieilBR letamed is iinrasable: 

wahcJwsXg ^^' 8UbMquWI """"P* * obtain a read lock migMsuccesd 

can_write - proc (aa: atomie_array(tD "*ume (boot) 

""■J**? t "** a l w,,to lock could be obtained on aa without waiting, otherwise 
Z^Z^J^t^^S™"*- Evenitneexeoi^actiw^SowT^ 

™^Sf A^S. 00 ? *omfc_array «t any time, the information returned is uoreiabte 

jvw» Weeje returned, a aubsequent attempt to obtain a wrtte lock irtgtTsuccsed 

read_lock - proc (aa: atomic antyffl) 
effects Obtains a read tock on aa. 

write_tock - proc (aa: atomtc_afiay[t]) 
effects Obtains a write lock on aa. 
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similar - proc (si, s2: st) returns (boot) sJgnsJs (faHure(str1ng)) 

require each tf has similar: proctype (t,, ty returne (boot) signals (f aHure<aUtag)) 
sffscts Returns true K a 1 and a? contain similar objects for each component as deteimined 
by the f^5im*ar operations. Any ftftae signal Is i mm e d i a tely resignaHed. This operation 
does not toetf originate any taHun signal. The comparison is dons in lexicographic order 
of the selectors; if any comparison returns falae, falee is returned immediately. 



copy - proc (s: st) returns (st) signals (faNunXatrtag)) 

requires each t, has copy: proctype (ty returns (ty si gna ls (faaurejetrtng)) 
effects Returns a struct containing a copy of each component of a; copies are obtained by 
caWng the tpoopy operations. Any faUun signal is immedtoteiy reeignailsd. This 
operation does not Rsstf originate any failure signal. Copying is dons in lexicographic 
order of the selectors. 

transmit - proc (s: st) returns (st) signals (faHure(strtng)) 
requites each t, has transmit 

effects Returns a struct containing a transmitted copy of sach component of s. Sharing is 
preserved among the components of s. Any Ajflum signal from ^transmit is 
immediately resignaHsd. This operation does not Itself originate any teflure signal. 

11.12. Records 

record - datatype [n,: t, i\: y Is r_gets_r, r_gete_s, setj^ sstj\, gern, getjv, 

ecjual,similar, simHsn , copy, oopyl , ttaraimlt 

Overview 

A record is a mutable collection of one or more named objects. The names are cased selectors, 
and the objects are ceded components. Different components may have different types. A record 
also has an identity as an object. 

An instantiation of record has ths form: 

record [ field_spec ,... ] 
where 

field spec ::= name, ... : type actual 
(see Appendix I). Selectors must be unique within an instantiation (Ignoring capitalization), but the 
ordering and grouping of selectors is unimportant. For example, the fosowtag name the same 
type: 

record[last, first, middle: string, ags: tat] 

rscordpast: string, age: tat, first, middle: string] 

A record is created using a record constructor, sse Section 6.2.1 1 . 

For purposes of ths certain operations, ths ths names of the selectors aw ordered 
lexicographically. Lexicographic ordering of the selectors is the alphabetic ordering of the selector 
names written m tower case (based on the ASCII ordering of characters). 

In the following definitions of record operations, tot rt - lacoreTn, : t t t\: y. 

Operations 

rjjets_r - proc (r1 , r2: rt) 
modifies rf. 
effects Sets each component of rf to be the corresponding component of r2. 



\ wk \ Mmmmt^ mmmmmmmmmmmmmmmmmmmmmm 
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11.12 Records u 

11.13. Atomic Records 

afomte.record-dstatypeln^ rv y to ar_geto_ar, «^t_ ni eeuv.get n. get rv, 

ar2r, r2ar, equal.slmitor, timiton . copy, oopyl , trams*, ~ ~ * 

test.and.read, test_and_write, canraad, canwrite, roadblock, wntejock 

Ovarvtow 

Anatomtej^coidteamutabteateniksooltocll^ Thenamesare 

^*!£2!!!J^^^ Di^anloomponanteniayhavadWefent 

types. An aiomtojecoid also has an identyss an object. 

An instantiation of atonricracord has the form: 

atomlcjecord [ field spec , ... 1 
where 

ttoJd_spec ::= name, ... : type spec 

< ^S?jS5P°!]^ x IJ - S f tect0f8 "*•* *» *" **« * m*n m i n ste n Se ticn (ignoring capaateatten), but the 
ordering and grouping of selectors to unimportant. For example, me following name the same 
type: 

atomtejaeofdflast, tost, middle: string, age: kit] 

atomte_mcord[last: string, age: tat, first, mkJdto: string] 

An atomic_record is created using a toomtejecord constructor, see Section 6.2.1 1 . 

For purposes of the certain operations, the the names of the selectors are ordered 

texte °W5 tea 5f- J^toW* w*** of the sstoclors to the aiphabetk: ordering of the selector 
names written in tower case (baaed on the ASCII ordering of characters). 

fi!!25r£fy d l Lu 86 read/ " ri J e locWiig to achieve atoinJcey. The locking rules are described in 

r^ll^y^^ ^^!!!^ As deflned bstow, the only 

operation that (in the normal case) does not attempt to test or obtain a tock to the equal operation. 

In the following, tot art - atomic_rsoord{n 1 : t,, .... n,,: y. 
Operations 

ar_gets_ar - proc (r1 , r2: art) 
modrftesrr. 

sftocts Obtains a write tock on n and a read tock on r2, then sets each component of n to 
be the corresponding component of r2. 

get_n, - proc (r: art) returns (ty 

effects Obtains a read tock on rand returns the component of r whose selector is n. There 
is a gef_ operation for each selector. 

set_n,- proc (r art, e:tj) 
modHtesr. 

effecu Obtains a write lock on rand modifies r by making the component whose selector is 
n f bee. There is a «er_ operation for each selector. ^^ 

a^r- proejar: art) returns (r. art) 

effects Obtains a read took on ar and returns a record rwlth the same state. 
r2ar - proc (r: art) returns (ar: art) 

eftects returns an atomfc_record arwith the same state as r. Obtains a read took on ar. 
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equal - proc (rl, r2: art) raturna (tool) 

effects Returns trua if rl and r2 are the very same atomic record object; otherwise returns 
false. No locks are obtained. 

similar - proc (rl , r2: art) retume (tool) eignolc (faHurefatring)) 

roqulroa each t, has similar: proctype (t,, ty raturna (toot) eignate (faHure<atrtng)) 
affaeta Obtains areadiockon /^ then areadtockon/2; then comperes correaponding 
components from rl and r2 using the tfiaknHar operations. Any refer* signal is 
immediately resJgnaited. This operation does not itself originate any wfere signal. The 

^S^^^^J^^ 91 ^ ^ 01 ^ *—*K » *V cornpaneon returns 
faiee.fatee is returned imniediately. If ail conparisons return taie, returns true. 

similart - proc (M , r2: art) retume (tool) eJgraat (faHure<strtng)) 
^raa each/, has <^: proctype (t^i^turoeftoo^ 

affaeta This operation is the same as similar, except that fieque/ is used instead of 
tf&mUar. ^ 

copy - proc (r: art) returns (res: art) eignale (facetting)) 

roqulroa each t, has copy: proctype (ty retume (ty aignale (faHure{etrfng)) 
effects Obtains a road took on r, then relume a new atomic record roc obtained by 
performing copyM and then replacing each coripoiwtwlma*copyo<mecone«ponding 
component* r. &^v*o*a*ritycaM^mtjkapycp«atk>m. Any wfero^gnal 
te inmedtotety reaignaaad. This operation does not tee* originals any Art** signal. 
Copying is done In toxioographic order of the salectore. A read lock to also obtaJnad on 
the new atomic_record res. 

copyl - proc (r: art) retume (res: art) 

effects Obtains a read tock on r, then retume a new atomte record res containing the 
components of r as its components. A read took is atoo obtained on the new 
atomtejeoord res. 

transmit . proc (ar: art) retume (art) aignala (facetting)) 
raquMee each 4 has transmit 

-,l,c,g «55 n V "** •*"*-•»««* containing a transmitted copy of each component of 
ar. Sharing to preserved among trie components of ar. A read took is obtaJnad on ar and 
the new atomic_anay. Any faUun signal from ptranemll to Immediately restgnatted. 
This operation does not ttsetf onginatewiymflure signal. 

test_and_read - proc (ar: art) raturna (tool) 

affettaTrtes to obtain a read lock on ar. if the tock is obtaJnad, returns true; otherwise no 
tock is obtained and the operation returns fatoe. The operation does not MreT for a took. 
r^l^^J^^"?^." to T t " ,hat » tock ©at* to obtained, foieo may be 
SaM JftS watthj W ^' * 8ub • eque, * ai,mpt to obtato a read tock might 

test_and_wrlte - proc (ar: ait) returns (tool) 

#W !SI'S t i!?^L a J! rito,0Ck0ftlr ' K,ne to* «• obtained, returm true; otherwise no 
tock is obtained ano^he operation returns fatoe. The operation does not ■watt" for a tock. 

^ZL^ ****** *?<" "to""*" «* • took oouid be obtained, Mae may be 
sSw^wa^ 
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vakie_n, - proc (o: ot) returns (ty signal* (wrongjag) 

affects If the tag of o is n h returns the value of o; otherwise signals wrong Jag. There is a 
value_ operation for each selector. 

o2v - proc (o: ot) returns (vt) 

effects Here vf is a variant typs with the same selectors and types as ot Returns a new 
variant object with the same tag and value as o. 

v2o - proc (v: vt) returns (ot) 

effects Here vf is a variant typs wan the sams selectors and types as ot Returns a oneof 
object with the same tag and value as v. 

equal - proc (o1 , 02: ot) returns (boot) signals (feaure(str1ng}) 

requires each t, has equal: proctype % ty returns (boof) afgmto (faJlure<strtng)) 
sffscts Returns bus if of and o2 have the same tag and equal vsktes as dete«miRed by the 



aqua/ operation of their data parrs typs. Any asKre signal is iiwialaUlj resignalsd. 
This operation does not ilsetf originate any Mure signal. This operation is dMsfeb) at the 
call of tjlequal. 

similar - proc (ol , o2: ot) returns (boot) signals (f aaure(stitag)) 

requires each f, has similar: proctype (t,, g returns (boot) signals (faJure(strmg)) 
sffscts Returns bus if of and o2 have the same tag and sfcnBar values as determined by 
the similar operation of their value's type. Arty /Mure signal is immediately resignalled. 
This operation does not Itself originate any /aflure signal. TNs operation is dMsfels at the 
call of tjtstmllar. 

copy - proc (o: ot) returns (ot) signals (faNure(strtng)) 

requires each /, has copy: proctyps (t,) returns (y slgnale (faJure(stilng)) 
sffscts Returns s oneof object wan the same tag as o and containing as s value a copy of 
os value; the copy is made using the copy operation of the value's typs. Any failure 
signal is immediately resignalled. Thle operation does not toe* originate any failure 
signal. This operation is dMsbte at the caH of tficopy. 

transmit - proc (o: ot) returns (ot) signals (fsHurs(strtng)) 
requires each t, has transmit 

sffscts Returns a oneof object with the same tag as o and containing as a value a 
transmitted copy of os value. Any taHum signal is immediately resignalled. This 
operation does not itself originate any faHun signal. 

11.15. Variants 

variant - datatype [n,: ^ nj,: y Is makeji, makejv. change^ change_n k , 

isj^, .... bj\, vaJueji,, .... value.^, vjgsts v, vjgetsj), 
equal, similar, similarl, copy, copy?, transmit" 

Overview 

A variant is a mutable, tagged, discriminated union. Its state is a oneof, that is, a labeled object, 
to be thought of as "one of" a set of aJtematwss. The label is catted the tag part, and the object is 
called the value (or data part). A variant also has an identity as an object. 

An instantiation of variant has the form: 

variant [ fiekj_spec ,... ] 
where 

fieid_spec "s name, ... : type actual 
(see Appendix I). Tags must be unique within an instantiation (ignoring capitalization), but the 
ordering and grouping of tags is unimportant. 
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Although there are variant operations for decomposing variant objects, they are usually 
decomposed via the tagcaae statement, which is discussed in Section 10.14. 

In the following let vt - variant^: t, ry y. 

Operations 

make_n, - proc (e: y returns (vt) 

effects Returns a new variant object with tag n, and values. There Is a make operation for 
each selector. 

changeji, - proc (v: vt, e: t,) 
modifies v. 

effects Modifies v to have tag n, and value e. There is a change operation for each 
selector. ~~ 

is_n, - proc (v: vt) returns (boot) 

effects Returns true If the tag of v is ty otherwise returns false. There is an fe operation 
for each selector. ~ 

value.n, - proc (v: vt) returns (y signals (wrongjag) 

effscte If the tag of vie n ¥ returns the value of r, otherwise signals wrongjag. There is a 
vafue^ operation for each selector. 

v_gets v - proc (v1 , v2: vt) 
modifies vf. 
effects Modifies vl to contain the same tag and value as v2. 

v_gets_o - proc (v: vt, o: ot) 
I v. 



effects Hsrs of is the oneof type with the same selectors and types as v*. Modifies v to 
contain the same tag and vsJus as o. 

equal - proc (v1, v2: vt) returns (boot) 

sffscts Returns true if v1 and K?are the same variant object. 

simHar-pr©c(vl,v2:vt)retunw(bool)e^ 

requlree each t, has sfenssr: prectyps fy y istim (bsof) stgiuUs (f ailure<stnng)) 

f*^°P^f^ of Rvalue's type. Any mm signs! is Immiclotilj rsefcjisssd This 
opjmtofl idoes not Use* originate any fefere signet. This operatton is dMetfte at the call 
of tjfamHar. 

similarl - proc (vl , v2: vt) returns (boot) signals (fasursfatrlng)) 

requlree each t, has squat: proctyps (t,, y returns (boat) slgnsls (fa*ure(strlng)) 
sffscts Same as similar, except that tfauaJb used instead ottfisJmiiar. 

copy - proc (v: vt) returns (vt) signals (fasur^strlng)) 

requlree each t, has copy: proctyps (y returns (V signsis (fa«ure(strtng)) 

sffscts Returns a variant object with the same tag as v and opining as a value a copy of 

«! va ^', itm W * """^ u8lnB ** °^ «PW*« ; oi ths value's type. Any failure 
dgna IsimmsdiatsJy rssignassd. TWs operation doss not Itself originate any failure 
signal. This operation is dMstote at the caH of l^sccpy. 

copyl - proc (v: vt) returns (vt) 

effects Returns a new variant object with the same tag as v and containing Vs value as its 
value. 
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transmit - proc (v: vt) ratunw (vt) aignait (faMure(etrtng)) 
requires each 4 has transmit 

affaets Returns a variant object with the same tag as v and containing as a value a 
transmitted copy of Vs value. Any taUure signal is immediately resignalted. This 
operation does not itself originate any faBun signal. 

11.16. Atomic Variants 

atomlcvarlant - data type |n,: t, n^ y la meton, make ru. change n, , change rw, 

avjgets_av, Js_n t Isjv, valuejt,, .... value jv, av2v, v2av,~ 

equal, similar. simHarl , copy, copyl , tranemft, 

test_and_read, test_and._write, can_read, canwrlte, readjock, write_lock 

Overview 

An atorrticjrariant is a rrajtable, atom^^ Ms state is a enaof, that is, a 

labeledobject.tobethougrtrtas^jntoraselofaltwTiaaves. The label is called the tag part, 
and the object is catted the value (or data part). An atomic variant aJao has an identity as an 
object ~" ' 

An instantiation of atomlc_variant has the form: 

atomlc_varlant [field spec , ... ] 
where 

fleM.spec ::= name, ... : type actual 
(see Appendix I). Tags must bs unique within an instantiation (ignoring capitalization), but the 
ordering and grouping of tags is uriirnportant. 

ARhough there are atomic_variant operations for decomposing atomic variant objects, they are 
usually decomposed via the tagteet statement or tagwaft statementTwhlch are discussed in 
section 10.15. 

In the following, let avt - atomk^variarrtfn,: t,, .... r\: y. 
Operatlona 

make_n, - proc (e: ty raturna (av: avt) 

effects Returns a new atornfc_variant object av with tag n, and value e. Obtains a read lock 
onav. There is a ma*e_ operation for sach selector. 

change.n, - proc (v: avt, e: t,) 
modifies v. 

effecta Obtains a write lock on v, then modifies v to have tag n, and value e. There is a 
change^ operation for each selector. 

avjgets_av - proc (v1 , v2: avt) 
modifies W. 

effecta Obtains a read lock on v2 and then a write lock on vl, then modifies vl to contain 
the same tag and value as v2. 

\&j\ - proc (v: avt) raturna (bool) 

effecta Obtains a read lock on v, then returns true if the tag of v is m otherwise returns 
false. There is an fe_ operation for each selector. 

vahje_n, - proc (v: avt) raturna (ty slgnata (wrongjag) 

effecta Obtains a read lock on v. Then, If the tag of v*n h returns the value of v, otherwise 
signals wrongjag. There is a value_ operation for each selector. 
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av2v - proc (av: avt) returns (v: vt) 

effects Here vt is a variant type with the same selectors and types as avt. Obtains a read 
lock on av and returns a variant v with the same state. 

v2av - proc (v: vt) ratunw (av: avt) 

effects Here vt is a variant type with the same selectors and types as avt. Returns an 
*ornto_variant avwith the same state as v. Obtains a read took on av. 

equal - proc (v1, v2: avt) returns (boot) 

affects Returns true it vl and v2 are the same atomic variant object. No locks are 
obtained. ~~ 

similar « proc (vl , v2: avt) returns (boot) signals (faJlure(etimg)) 

raqutros each f, has similar: proctypa (t,, ty returne (beef) elgnais (faifcre(sti1ng)} 
sftects Obtains read locks on vl and ¥2, m orosr, and then compares the objects; returns 
true H vi and v2 have the same tag and starter values as determined by the shnUar 
operation of their type. Any faitun sjgnai is Immsiialslj itHgnassd. Thto opsratton does 
not itself originate any faitun signal. Thto operation to dk%t* at the call of tfi$kr#ar. 

similan - proc (vl , v2: avt) returns (boot) stgnaie (faJJure(efe1ng)) 

requiree each t, has equal: proctypa (t,, ty rasuma (boof) aignais (faHure(strtng)) 
effects Same as similar, except that tfiequai Is used Instead of f^s/mtfa-. 

copy- proc (v: avt) returns (avt) stgruas (f aitore<atr1ng)) 

requires each t, has copy: proctypa (y returne ty stanata (talure<strlng)) 
affscts Obtains a read took on v, then returns an atom* jrartara cibjed wim the sajna tag as 
v and containing as a value a copy of fa value; the copy is made using the copy 
operation of the value's type. Any tafeuro signal is Immediately resfenased. This 
operattonoowrwtih^OTitfnaleafly/Wurssio^aJ. This operation is dtvtoUs at the call 
Gltjlcopy. A read lock Is obtained on the reeut. 

copyl - proc (v: avt) returne (avt) 

affacta Obtains a read tock on v, then returns a new atomic_variant object with the same tag 
as v and containing v-s value as its value. A read tock to obtained on the resuK. 

transmit - proc (v: avt) returne (avt) signals (faMurs(strlng)) 
requires each /, has transmit 

affscts Returns an atomtojrariant object with the same tag as v and containing as a value a 
transrnNtadoopy of vs value. Obtains a read lock on v. Any taKun signal is immediately 
resignaNed. This operation does not Bee* originate ariy tafrre signal. 

test_and_read - proc (av: avt) returns (boot) 

e«ectaTrk« to obtain a read lock on av. if ths took is obtained, returns true; otherwise no 
tock » obtained and the operation returns tatae. Tr» oceratton does not "war kx a lock. 
Even If the executing action -knows' that a took ooukl be obtained, tatae may be 
returned. Even R tatae is returned, a subsequent attempt to obtain a read tock might 
succeed without waiting. 

test_and_write - proc (av: avt) returns (boof) 

affscts Tries to obtain a write tock on av. If the tock is obtained, returns true; otherwise no 
took is obtained and the operation returns fates. The Of>eratien doss riot NraT for a tock. 
Even if the executing action -knows" that a took couW be obtained, tatae may be 
returned. Even if fates is returned, a subsequent attempt to obtain a write tock might 
succeed without waiting. ^ 
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canjead - prae (av: avt) mums (boof) 

•"?? ""Si? *** ' ■ l "* te * GOuW *• o*»toed on av without waiting, otoorwiee 

locked be octoirtecttotooniey be retomed. ftmiwi comment action may obtain 

^STZiSi^^ **&■ »« « *»» »• J** ** * * rafcraod it unneebto: 
even I tmo it lotom od. a utoaequaie «awpf te abtoto too took may r on ufce w tol ng. ind 

StnoJltSSno 1 * """""^ * ,l * ,, • ,, " , *^ * *■*» • ••* to* mkjht ejected 



can jwnte-prae (av: avt) nttume (boot) 

•"SSJIISK ^ JL? ?** ** "^ ** q * a,B,d •" " "a* ** w * ,in 8. <«wwtoe 

or raeeoe a ioox on an atofNcjontnt at any tone, toe MmmMm returned it umalablt' 



even * tmo it returned, a „ ^ _ _„ _ _ wwwmr _ ***** mm 

SnotiJBtTiT * lta,,i-r * ■•NNWt «■*** to obtain a wnto look might succeed 

read_lock - prae (av: avt) 

offaota Obtain* a mad lock on av. 

write Jock - prae (av: avt) 

offaeta ObtaJra a write lock on av. 

11.1 7. Procedures and Iterators 

practypo - data type la equal, totter, copy 
Rortypo - date type to equal, tetter, copy 

Overview 

gg^J* »?»» ■» °^ «» «* » *» * *»****■ The type epednsatien for a 
r^^ U ^ im S SiTT. L^^""^ to •praoadyni or ftorator needng; e 



Prectype(C^pe.tpec,...l) [ returns Hsignelt] 

and an Iterator type apedfeatton bat the term: 

"•*Wto<[type_tpee,...J) [ ytoldt J [ eignale ] 

where 

retornt ::s ratume (type_epec , ...) 

ytokte ::= ytokta (type_spec , ...) 

signals :;s tigneie (exception , ...) 

exception ::a name f (tvpe_apec , ...) ] 

nZE?£ v£L?K Z^J^£Zl*J!^>^^^«**^*» 

i vhw tevM VI jrfe^MVw* I HP f^TaV wKISoT etopera aW ^MMMtMeS eWHatf «W «tl0 BftKMffclM Of latt^fc&l** tflU" 



*•**■ ■ *^ww w» y^o^Mpaeee* inv o^eSPraooV waHeto'eeVraaTeal ttfli H'sB^nft-'flMta^aflyM AT-lteiiaBttf* ftrai* 

^"•^"^^••NPetooto^raiiaietbeia^ie. *- i to tin if ■nitntoim H mil. 

For example, both of tto to t o w fag type i ■■■■■ Jrrs *- *: ■-■— ^ ~-.--»«ew-i 



pcoctypo(otrtng,tot, tot)raemn (otrlnej ttoaoto ifimuk. mpiiii etee) 
praetype (etrtng, w, tot) n*um. <«**) e?S(^ia^^rbbi«J») 
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^SS^^^SI^^,^^^ """P** "***" <«* by the Wild expression, 

wimutaoie and atomic in normal use. However, some ueee of own data {see Sactfan 19 ^ in 
procedures and iterators can violate this tMonvt ^^ "^ w «^ *^ <^ S**^ ^.Z) in 

In the following operation descriptions, t stands for a proctyps or Kertype. 
Operations 

equal - proc (x, y: t) returns (bool) 
similar - proc (x, y: t) returns (bool) 

^^Sl^S^JS'Z 1 ^ Mm *l3f"! ««/ are the same implementation of 
me same abstraction, with the same parameters (see Section 12.6). 

copy - proc (x: t) returns (t) 
effects Returns x. 

11.18. Handlers and Creators 

handlertype - data type It equal, similar, copy, transmit 
creatortype - data type la equal, similar , copy, transmit 

Overview 

Handlers and creators are created by the Argus system. The type specification for a handler or 

n«itfertype([type_spsc,...]) [returns] [signals] 

and a creator type specification has the form: 

cr **ortyi»([typ8_sp6c,...])[ returns] [signals] 
where 

returns lis returns (type_spsc , ...) 

signals lis signals (exception , ...) 

exception ::= name [ (type_spsc , ...) ] 

ine number, types, and order of the objects to be returned are aJss given AH namaSuaad in a 
••■IS? ^ mu * * ""V*: "•"• «« bs uria«tfat*oM»X»;Xn havTa^fiined 
meanmgfor remote cass (see Section 8.3). J^^S^SJ^^ilSnMV^ 

£2SEf ^ZSSFSl con ^ m ^ modute ». «* nandlsrs are created as a side-effect of guardian 
hraSL* EFXS? "T «•;■""**■ ** « considered to bs immutaS anSSSc 
m normal use. Certain uses of own data in handlers can violate this assumption. 

In the following operation descriptions, /stands for a handlertype or creatortype. 
Operations 

equal - proc (x, y: t) returns (bool) 
similar - proc (x, y: t) returns (bool) 

•"•eta These operations return true Handontyifxandyarethe same obiect feea Sartinn 
12-6 for an exac* definition for the casso^^ 
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copy - proc (x: t) mums (t) 
transmit - proe (x: t) returns (t) 
effect* Returns x. 



11.19. Anys 

any - data type la create, force, tejype 
Overview 



Operations 



j^a^w^stw^aaaRLff- •— — — - 



create - prec[T: type] (contents: T) returns (any) 

aflacta Returns an any object containing content* and the type r. 
force . jrrocpv type] (thing: any) returns (T) signais (wrongjype) 

^rw£f£^^ 
is_type -proc(T: type] (thing: any) returns (boot) 



II.20. Images 

Image - data type la create, force, tejype, copy, transmtt 
Overview 

Operations 

enm ^SSSj l BSS SS L i ^ wlum, (lmaflt) • ,fl,,a,, i w,m '*« 

forCe "riq^ TO^ r,,llrn • ™ , * n,,i f^"*- 1 **' faftiie(atimfl)) 

""SlVfSrSbS •"oS?! 7 "' »"" that <*** is extracted 

uwng me aeooaa operation of 7 and returned. Otherwise nmno fen* ** c^oil^ 

ResignaJs any Mb» signal raised by jiSSmSSST " TW *- ( ** te t ^ 0mL 
te -^^{ffj^-*~8*) "*«"• (bod) 



copy -proe (thing: Image) returns (Image) 
transmtt- proc (thing: Image) returne(image) 
affects Returns thing. 
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11.21. Mutexes 

mutex - data typoft: typa] la create, set_value, get_vakie, changed, equal, similar, copy. tranamN 
Overview 

A mutex is a mutable container for an object of type t A mutex also has an identity as an object. 

An object of type mutexjt] provides mutual exclusion lot process synchronization, and allows 
exphctt control over how Information contained in the mutex is written to stable storage (see 
Section 15.1). 

The seize statement is used in order to gain possession of a mutex. See section 6.7. 

Although mutex objects are mutable, sharing among rnutex objects is uauaNy wrong, because the 
contained object should only be aoosssMe through the mutex. Hence there Is no copy* 
operation, since this would introduce sharing, and there Is no atotiarl operation to check for 
sharing (see Section 6.7). 

Operatlona 

create - pree (thing: t) returns (mutexft]) 

effects Returns a new mutex object containing thing. 

8et_vaJue - proc (container: mutexp], contents: t) 
modrflee container. 
aliacta Modifies container by replacing its contained object with contents. 

get_value - proc (container: mutexft}) retume (t) 

effects Returns the object contained in container. 

changed - proc (container mutex{t]) 

effects informs the Aigus system that the calling action requires the contents of contt/ner to 
be copied to stable storage by the time the action commits, provided container is 
access** ftom a stable variable. It is a programming error If a process that is not 
running an action cafe this operations, and If this is dene the guardian wW crash. 

equal - proc (ml , m2: mutexft]) returne (boot) 

effects Returns true If and only If nrf and m2 are the same object. 

similar - proc (ml , m2: mutexft]) returns (boot) ajgnait (falure(atrlng)) 

requires it has similar: proctype(t, t) returno(boe4) algnate (tailure(etrtng)) 

effects Seizes ml, then seizes m2, and cafe t&miarto determine Its result; any failure 

signal is immediately resignafed. Possession of both mutexes is retained until ^similar 

terminates. 

copy - proc (ml : mutexft]) returns (m2: mutexft]) signs* (faaure(etrmg)) 
requlraa t has copy: prectypa(t) returned) aJgnafe (faiure(etring)) 
effecta Seizei imf, then cafe tcopyto make a copy which it pteces in the new mutex obtect 

m2. Any mm signal is immediately resignafed. Possession of mf is retameduntil 

t$copy terminates. 

transmit . proc (ml : mutexft]) returns (mutexft]) eigneJe (faHure(atring)) 
requireethastranemlt 

effecta Seizes ml, and returns a new mutex containing a transmitted copy of the contained 
object. Any fatt^ signal is immediately resignafed. Possession of mr is retained until 
StranatiHt terminates. 
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Appendix III 
Rules and Guidelines for Using Argus 

This appendix collects the rules and guidelines that should be followed when programming in Argus. 
Following these rules makes seize statements meaningful, actions atomic, and so on. In some rare 
cases there may be vaHd reasons for violating mess guidelines, but doing so greatly increases the 
difficulty of building, debugging, and running the resulting system. 

All of the rules listed in this appendix are based on information appearing elsewhere in the manual. 
Each rule is followed by a brief rationale, including a reference to the section of the manual from which it 
is drawn. 

111.1. Serializability and Actions 

• Actions should share only atomic objects. 

Rationale: Actions that share non-atomic data are not necessarily seriaflzable. [Section 2.2.2] 

• A subaction that aborts should not return any Information obtained from data shared with other 
concurrent actions. 

Rationale: Returning such data may violate seriaiizabiUty. [Section 2.2.1] 

• A nested topaction should be seriaJizabis before its parent. This is true If either 

1. the nested topaction performs a benevolent side effect (a change to the state of the 
representation that does not affect the abstract state), or 

2. all communication between the nested topaction and its parent is through atomic objects. 
Rationale: Other uses may violate seriaHzabiHty. [Section 2.2.3] 

• The creation or destruction of a guardian must be synchronized with the use of that guardian via 
atomic objects such as the catalog. 

Rationale: Otherwise serializability may be violated. [Section 10.18] 

111.2. Actions and Exceptions 

• If an exception raised by a call should not commit an action, the exception must be handled within 
that action. 

Rationale: If an exception raised within an action body is handled outside the action, the implicit flow of 
control outside of the action wNI commit the action. [Section 1 1 .5] 
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111.3. Stable Variables 

• Stable variables should denote resilient data objects. 

Rationale: Only data objects that are (reachable »rom tr» stable varW^ and) resilient a^ vi^en to 
stable storage when a topac^ commits. (This can be ensured by hiving stable variables only denote 
obj«*s of an atomic type or objecte protected* ******** ********** 

are only written to stable storage when the guardian is created. [Section 13.1] 

• If a bound procedure or iterator will be accessible from a stable variable 

1. the procedure or iterator being bound must be atomic and 

2. only atomic objects should be bound as arguments. 

Rationale: The bound procedure or iterator may be stored h stable storage. arKl non-atornlc data Is 
only written to stable storage once. [Section 9.8] 

111 .4. Transmission and Transmisslbility 

• An abstract type's encode and decode operations should not cause side effects. 

flatfo/M^: The riumber of calis to an anec^ or o>^ 
results rray be encoded arri decoded severaJtimssM |n 

addition, verifying the correctness of transmission is sasisr if encode and decode are simply 
transformations to and from the external representation. [Section 14.3] 

•Ifthe naming relation among objects to be transmWsd is <^ (..g., a ctolar list) then enco^ 
decode must be implemented m one of two ways: 

2. The external representation object must be acyclic. 
Rationale: A circular external representation may cause decode to faH. [Section 14.4] 

• Objects that share other objects should be bound into a handier or creator m the same bind 
expression. 

Rationale: Sharing is only preserved among objects bound at the same time. [Section 9.8] 

IH.5. Mutex 

• Mutual exclusion or atomic data should be used to syiichronize axess to a« shared objects. 
Rationale: In the presence of concurrency, any interieaving of IndMsfcte events Is possible Without 

^!^^J^ e ^!^• ^ 0OOCurw ^ -« *»• >«". to p^grmms. signiricantly oomp«o««nQ 

coding and testing. [Sections] 
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• AH modifications to mutex objects should be made inside seize statements. 

Rationale: The system win gain possession of a mutex object before writing it to stable storage; thus, 
seizing a mutex in order to modify it wM prevent the system from copying a mutex object when it is in an 
inconsistent state. This also prevents other processes from seeing Inconsistent data [Section 15.2 and 
Section 15.1] 

• Nested seizes should be avoided when pause is used, and pause must be avoided when nested 
seizes are used. 

Rationale: A pause in a nested seize does not actually release possession of the mutex object. 
[Section 10.17] 

• if an object is referred to by a mutex object, it should not be referred to by any other object, nor 
should it be denoted by a variable except when in possession of the containing mutex. 

Rationale: If an object contained in a mutex can be reached by a method other than seizing the mutex, 
the mutual exclusion property of the mutex is undermined. [Section 6.7] 

• No activity that is Ukety to take a long time should be performed white in a seize statement. In 
particular, programs should not make handler calls or wax^ locks on atonfe objscte white in possession 
of a mutex. 

Rationale: Waiting for a lock while in a mutex is Nkety to cause a deadlock with other actions or 
between the action holding the mutex and the Argus system. [Section 15.3] 

• Mutsx objects should not share data with one another, unless the shared data is atomic or mutex. 

Rationale: Sharing of non-atomic objects between mutex objects is not preserved when the mutexes 
are written to stable storage. [Section 15.3] 

• Mutex[fl$changeo* must be catted after the test modification (on behalf of some action) to the 
contained object of a mutex. 

Rationale: The Argus system is free to copy the mutex to stable storage as soon as mutextpcnanged 
has been called. Changes after the test can to imfta***!*^ but before to^ 
be written to stable storage. [Section 15.3] 

• Mutext4$changed should be called even if the mutex object changed is not accessible from the 
stable variables. 

Rationale: In a scenario where the object was access**, becomes Inaccessible, then becomes 
accessible again, it is possble that stable storage would not be updated properly if this rule were not 
followed. The system guarantees that no problems with updating stable storage wfll arise if 
mutexfftcnanged is always called after the last modWcatton to the object. [Section 15.3] 
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• An atomic type implemented with a representation consisting of several mutex objects should use 
separate topactions to ensure that the mutexes are written to stable storage in an order that preserves 
the correctness of the representation. 

Rationale: Mutexes are written to stable storage incrementally. Sometimes, subtle timing problems 
can be caused by incremental writing if this rule is not followed. [Section 15.3] 

III.6. User-Defined Atomic Objects 

• If an atomic object Xof type T provides operations 1 and 2 , and action >» has executed 1 but not 
yet committed, then operation (^ can be performed by a oortcun^actionSonlyif O, and O^cornmufe: 
given the current state of X, the effect (as described by the sequential sp««catk>n of 7) c^ pwfomTing 
0,, then Og is the same as performing 2 , then O,. "Effect" includes both results returned and the 
(abstract) state modified. 

Rationale: There are two concurrency constraints for user-defined atomic objects: 

1 . An action can observe the effects of other actions oiily If thoM actiom committed relative to 
the first action. 

2. Operations executed by one action cannot invalidate the results of operations executed bv 
a concurrent action. ' 

Two operations (or sequences of operations) that commite in their efrect on the abstract stM ^ 
be permitted to run concurrently, even if they do not commute m their effect on the representation of X. 
This distinction between an abstraction and its implementation is crucial m achieving reasonable 
performance. [Section 15.4] 

• If a user-defined atomic object is accessible from the stabte variables of some guardian, it should be 
written to stable storage whenever an action that modifies it commits to the top. 

Rationale: A user-defined atomic type that is not written to stable storage on topaction commit wH not 
be resilient. [Section 15.2] 

• The form of the rep for a user-defined atomic type should to one erf the following possfeiNties. 

1. The rep is itself atomic. Note that mutex is not an atomic type. 

2 " H^J^ i 5™ J, * x t^ !S!!!^ 'J? a »ynor»rono«j« type. For example, t could be atomic, or it 

type are coded In-line so that the entire type behaves atomteaJly. 
3. The rap is an atomic collection of mutex types containing synchronous types. 

type are never modified after they are initialized. That is, mutSon may be used to create 

X H!Slf 8tate of "^ *" obtect - ^ ««e this has been done me object must never be 
modtnea. 

Rationale: In any other case it wHI be impossible to guarantee the resilience or seriaHzabillty of the 
type's objects independently of how they are used. [Section 15.3] 
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III.7. Subordinate Where Clauses 

• A where clause requirement on a cluster as a whole should be used whenever the actual parameters 
make some difference in the abstraction. For example, in a *ef duster, the type parameter's equal 
operation must be required by the cluster as a whole, in order to preserve type safety and the 
representation invariant. 

Rationale: Argus assumes that requirements that are not placed on the cluster as a whole do not 
affect the semantics of the abstraction or the representation. [Section 12.61 
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Appendix IV 
Changes from CLU 

This appendix Nsts the changes made to Argus that are not upward oompatlbto with CLU, that is, those 
which are not merely additions to CLU and that would cause a CLU program to be illegal or to run 
differently. 

IV.1. Exception Handling 

Unlike CLU, which propagated unhandled exceptions (by turning them into failure exceptions) and gave 
the failure exception special status, unhandled exceptions In Argus are considered errors and always 
cause a crash of the guardian, and faUure is not given special status. AN exceptions signalled in a 
procedure, Iterator, handler, or creator must be declared m me routine's header, and there are no implicit 
resignals of failure exceptions. See Section 1 1 .6 for details. 

IV.2. Type Any 

The type any is now a type like any other type, with parameterized routines force, create, and isjype. 
Thus the CLU manual's notion of "typs inclusion" is no longer nsceasary (but there is a new notion of type 
inclusion in Argus, see Section 6.1). The anyffofce routine only signals %wong_type" If me any object's 
underlying type is not included in the type parameter given, but the type of the result of any$force is its 
type parameter. The anyfisjype routine returns false if the any object's underlying type is not Included 
in the type parameter given. The CLU reserved word "force" was eliminated from Argus, and the creation 
of an any object is never implicit in an assignment In Argus. 

IV.3. Built-in Types 

Several changes to the interfaces of the built-in types were necessitated by the changes to exception 
handling. SpedNcaHy, the following changes were made to the butt-In types. 

1 ' I*!!!J!?2? °P e 5 atlon8 oonGat > */*>**. s2ac ac2s, s2sc, and ac2s, can now ail signal Umtts. 
A string literal that would be too large to represent wIN not be compiled. 

2. The sequence operations m, HKjxtpy, addh, addt, and concat can now aK signal fflmte. A 
sequence constructor mat would be too targe to represent wtt not be compiled. 

3. The «iay (and atomte_array) operations create, predict set low, m, M copy, addh, and 
addl can now all signal limits. An array constructor that cannot be legally" represented wiU 
either not be compiled (» this can be detected at oonpfle time) or wtt signal limits. 

4. The cqpy operations of the structured butt-m type generators, and the /» copy operations 

01 , !*T K £ II nd a,r,y (and ■tomle-.ifray), alow me copy operattons of their type 
parameters to have a fe*/re(strtng) exception. They will reaignal such a re*** exception. 
(Note that the type inclusion rote allows a type parameter to be used even if its copy 
operation does not have exceptions.) 

5. The skrilar operations of the built-in structured type generators attow the simitar operations 
of their type parameters to have a feft/re(etrtftg) exception. They wM resignaJ such a failure 
exception. 

6. The equal operations of the type generators sequence, struct, and oneof, and the slmllarl 
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^S!?-.? f Hi 5?° »® neratore ■"■*■ "•«"«. a^ v*** (and their atomic 
fSSS^SL? 10 ^ the ^? < r' °P! M « ,l «w | <»* «w*f tM» parameters to have a te^etrtag) 
exception. They will resignal such a failure exception. 

7. The elements iterator and the a*nflar and aftnftarf procedures of the type generator army 
(and atomle.array) will raise a MurefaMng) exoe|)tlon if tlie array aioufnert is riiutated^ 
such a way as to cause a bounds exception when an element is fetched. 

IV.4. Type Inclusion 

Type inclusion (the new notion, see Section 6.1) is used in all contexts, including the dects of except 
and tagcase statements, where CLU had previously required type equality. 

IV.5. Where Clauses 

CLU had syntax in the where clause (specifically the production for op_name) that allowed one to 
require an instantiation of a type parameter's generator. The little used feature has been superseded by 
the mechanism described in Section 1 2.6. 

IV.6. Uninitialized Variables 

An uninitialized variable reference error is defined to cauee a crash of the guaro^, rather than raising 
a failure exception, which could conceivably be caught. 

IV.7. Lexical Changes 

Several new reserved words were added, in addition, the semteoton (;) was banished from the syntax. 

IV.8. Input/Output Changes 

The input/output data types (fite_name, stream, and (stream) and the Bbrary procedures described in 
appendix III of the CLU manual are not furnished by the Aigus system. Our current Implementation of 
Argus provides a keyboard cluster for input and a ptfrvam ckister for otjtput. m addition, most of the 
built-in types currently have print operations defined, tor pretty-printing objects onto patreams. These I/O 
mechanisms, however, are stHI experimental, and so are not documented In thte reference manual. 
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